[whatwg] onclose events for MessagePort

[Ian Hickson]

On Wed, 11 Dec 2013, Ehsan Akhgari wrote:
> >
> > Right, but isn't that considered a problem?
> 
> Sure, but please remember that bfcache is a (Gecko specific, last I 
> checked) optimization and where that optimization doesn't work, we just 
> fall into the regular behavior of every web browser.

It's part of the HTML spec, FWIW.


> In general, if we want to fix this problem, we should think about a way 
> to let the author specify that they want their page to be bfcached no 
> matter what it's doing, at the risk of putting it in the bfcache 
> breaking parts of the page.

I don't understand how we could do this in the case of a MessagePort 
sending an "I'm dead" message and disentangling when the other side is 
navigated. I mean, that's pretty fatal for the port.


> When we decide that is a problem worth fixing, we can discuss solutions 
> separately.  Making the change being discussed here will not make that 
> solution harder to specify or implement.

I don't understand why it wouldn't make it harder.


> > > and given the fact that currently a solution for the case where the 
> > > page is navigated away from will need to register an unload event 
> > > handler (which also disables bfcache) we will be in no worse spot 
> > > than we are today.
> >
> > For pages that register the unload handler, sure. But if we do this, 
> > we block _all_ pages that use MessagePorts from going into the 
> > bfcache, because there's no way to know if the other side has a 
> > registered handler for the event or not when you are navigated.
> 
> Note that as I suggestion before, we can only blacklist a page for 
> bfcache if the handler

...is registered, I assume.

Behaving differently based on whether a handler is registered or not is a 
violation of the platform's event semantics. The model is that events get 
fired regardless of whether a handler is present or not. We go to some 
lengths to keep that invariant.

In any case, finding out if the other side has a listener registered would 
need sync IPC, which seems like a non-starter to me.


> There are ways to avoid that synchronous IPC by delivering that 
> information alongside with other IPC messages that you'd have to deliver 
> regardless.

You don't have to do any sync IPC to remote processes when navigating, as 
far as I can tell. Can you elaborate on this?


> > The event approach has the advantage that a no-op implementation need 
> > be nothing more than an IDL attribute event handler, something which 
> > should be a trivial burden given how common adding those is on the 
> > platform.
> 
> I'm not sure if I understand this point.  A Promise-based API should be 
> just as easy to implement as a no-op (at least, given my understanding 
> of how we generate the Javascript bindings from WebIDL files in Gecko 
> these days.)

I don't understand how having something could be simpler than not having 
something. Maybe I'm missing something in the proposal.


> I can totally imagine this being harder in engines that don't do that 
> kind of code generation, but the same could be said about event handlers 
> too without knowing about the specifics of the implementation of the 
> engine.

The difference is that event handlers are all over the place, and other 
than hooking a handler, don't have any requirements on implementations.


> > Now, we could still handle your use case (Ehsan and I chatted about 
> > this on IRC yesterday; the problem is what to do if, for instance, a 
> > port is being passed across multiple processes, and the OOM killer is 
> > essentially chasing the end-point, killing processes before they can 
> > inform the final recipient that the source has itself been killed). 
> > There's two obvious ways to do it; one is an attribute, the other is 
> > to just send the event whenever a MessagePort is created if it's other 
> > side is already known to be crashed. The one with the least impact on 
> > no-op UAs is the event; that would also have the advantage of meaning 
> > you didn't have to know synchronously that the port was damaged goods. 
> > The problem with the attribute is that you might not get the 
> > notification that the port is ill-fated until after you receive the 
> > port, even though the 'error' event has already fired (or tried to 
> > fire) in some other process.
> >
> > So my proposal to handle this would be to send another 'error' event, 
> > basically any time you create a MessagePort that's entangled with 
> > someone who has crashed already.
> 
> I'd like to question whether that is a better API.  I can't think of 
> anywhere else on the web platform where we have an event handler that 
> fires in this specific manner (after the fact, and as soon as you 
> register a handler for that event.)

The event doesn't fire when you register a handler, it fires (well, it's 
queued) when the object is created.


> But a Promise based solution at least has the advantage that the 
> semantics of the Promise is well defined and consistent with everywhere 
> else in the platform that Promises are used.  Do you disagree that there 
> is a consistency and API quality issue here?

Yes. This seems the same to me as how an <iframe> gets a 'load' event when 
created, if it is created without a src="" attribute, for example.

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