Re: [whatwg] onclose events for MessagePort

On Sat, 7 Dec 2013, Andrew Wilson wrote:
> 
> Here's my point - let's say you have two UA implementations, one that 
> GCs aggressively when two ports are not reachable and are idle, and one 
> that never GCs entangled ports.
> 
> Two documents (A and B) are connected via entangled ports, but the ports 
> themselves are no longer reachable. However, document A has registered a 
> "channeldropped" handler on its port. In the aggressive UA 
> implementation, the ports have been GC'd. Now, document B crashes. In 
> this case, only one UA gets a "channeldropped" notification, which seems 
> like a source of incompatibilities - if you do something in this error 
> case, you're basically exposing GC behavior. You can argue that this is 
> OK since "document B crashes" is something that can't happen on-demand 
> (although I'd disagree in the case that an OOM can cause the document to 
> crash) - it's a dangerous precedent and I'm not sure this new |error| 
> event is useful enough to motivate this change (especially since you're 
> not generating this event in the case of things like page navigation or 
> user closing the document).
> 
> A page could already detect crashed documents by polling if it wanted.
> 
> > If the port is not GC'ed before the other side is destroyed, but could 
> > have been, then it exposes GC behaviour, but that seems like a very 
> > minor concern in this case, as noted in my response to Jonas above.
> 
> I think we disagree about whether exposing GC behavior is a "very minor" 
> concern.

Exposing GC _in general_ is a big problem. In general, exposing GC makes 
it possible for a popular Web site to accidentally rely on the specific GC 
behaviour of a popular browser, leading to all browsers being forced to 
implement the same GC, so that they can be compatible with the popular 
site and thus gain market share.

Exposing GC in this specific case, though, seems like a way less serious 
concern. In order for a site to rely on the exposure of GC in this 
situation, it first has to _rely_, for proper operation, on the popular 
browsing in question reliably _crashing_. Subsequently, for other browsers 
to be cooerced into also _crashing_ (and having a specific GC behaviour), 
first the popular browser's implementors have to decide to not fix their 
crash, and the popular site has to decide to not fix their reliance on a 
crash, and the popular browser and site have to remain popular with users 
even as they keep crashing browsers as part of their "proper" operation, 
and the other browsers have to decide that actually supporting that site 
is so important that they should replicate not just the GC behaviour, but 
also the crash behaviour.

I find it incredibly unlikely that all those conditions would line up.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 9 December 2013 03:07:38 UTC