w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
332 stars 56 forks source link

HTML General Review: Cross-Document Messaging #269

Closed travisleithead closed 4 years ago

travisleithead commented 6 years ago

Hello TAG!

This issue is part of the TAG's larger effort to review the HTML spec in its entirety--please see the original issue https://github.com/w3ctag/design-reviews/issues/174 for a summary of all the break-out issues.

The "Sections" are all the sections of the WHATWG HTML spec that should be reviewed as part of this issue. Where the spec section has associated Web Platform Tests, the specific WPT path is noted. While the primary focus of the review is the specification text, it can be helpful to review the related tests to help clarify algorithms or see interoperability conformance issues (or find issues with the tests).

The "Features" are just a sample of what you will encounter as part of this spec section, it's not meant to be exhaustive.

Here are some example suggestions for what to look for during the review, but don't limit to only these suggestions!

Sections WPT path Features
9.1, 9.4, 9.5 webmessaging MessageChannel, BroadcastChannel

Please provide feedback as (please select one):

travisleithead commented 6 years ago

initMessageEvent sadly cannot be removed for web compat I assume?

Edit: per Chrome status, usage has been dropping over the years to the point that use of this API is almost non-existent. https://www.chromestatus.com/metrics/feature/popularity#InitMessageEvent Maybe we can in fact remove it!

travisleithead commented 6 years ago

User agents are also encouraged to consider rate-limiting message traffic between different origins, to protect naïve sites from denial-of-service attacks.

Is this rate-limiting actually done in any UA's? Seems like general good advice to UA, but if none do it, perhaps it's not considered a major threat.

travisleithead commented 6 years ago

The message infrastructure (structured serialize) has no way of allowing for customization of serialization, unlike JSON, with it's toJSON check to enable an object to serialize an alternative representation. For many objects, we think there is likely some kind of custom toStructuredSerialize that should have a correlated reviver function that is related to the specific object (e.g., not a generic reviver function), which could be mapped via tag or Symbol to the graph. This feels like a significant missing part of the infrastructure.

Also, cloning is synchronous today, because the intermediate cloned structure is not visible to the web platform. For many applications, having an asynchronous structured clone process would be preferable, but raises questions as to what the representation of the intermediate object should be. Perhaps it could be an opaque object like an ImageBitmap or CanvasProxy.

slightlyoff commented 6 years ago

The lack of an onclose event in the MessageChannel interface presents a persistent usability hazard.

Previously offered arguments about GC observability have not withstood the passage of time. The addition of Web Audio Worklets, Shared Array Buffers, and Atomics have created fine-grained locking systems which were previously not available. Recently renewed work on Weak References highlights the ways in which observability across turns is not a threat. Read consistency is only required within the same turn, and it is easy to satisfy this requirement by adding one-turn latency in dispatching close notifications. This should have no adverse performance impact.

Please add port closed events!

slightlyoff commented 6 years ago

/cc @kinu @mattto @wanderview

travisleithead commented 6 years ago

9.5.1.2. Ports as the basis of an object-capability model on the web

This got the juices flowing. Alex pointed me to comlink, which does almost exactly what I was thinking--actually realize a capability API on top of a MessagePort object. It would be really nice to see this baked into the platform.

travisleithead commented 6 years ago

//cc @aliams for workers stuff.

travisleithead commented 6 years ago

Re: https://github.com/w3ctag/design-reviews/issues/269#issuecomment-407584290, section 9.5.4. is terrible advice regarding the polling system for detecting closed message ports. Close event would be the right way to rectify this..