[whatwg] onclose events for MessagePort

[Jonas Sicking]

On Wed, Dec 11, 2013 at 11:18 AM, Ian Hickson <ian at hixie.ch> wrote:
>> 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. I suppose you could
> optimistically bfcache it and then if any of the entangled ports report
> back that they had a listener for 'error' then you throw away the page,
> but that would actually bring about yet another problem, which is that we
> generally try very hard to make having a listener or not having a listener
> be otherwise indistinguishable. It would also actually require a
> synchronous IPC, or at least blocking on IPC in the case that the page you
> navigated to immediately called history.back().

I'm not going to be arguing for the proposal that you've currently
specced, since I prefer the one that I proposed at [1]. And google
also didn't seem too enthused based on their reply.

The proposal at [1] would indeed cause pages that hold a MessagePort
to not be bfcached if the other side "pin" its port. However this is
actually a design goal! If page A and page B are communicating with
each other, and A sends a message to B and want a reply, then our
design goal is for A to alter its behavior if B is navigated away from
before that reply is sent. This means that we can't by default bfcache
B.

This is an effect of the use cases that we are trying to solve, not an
effect of any particular syntax. Hence avoiding solutions because they
prevent bfcaching while communication is happening between the two
pages is the wrong reason.

The proposal at [1] does not prevent bfcaching *anytime* that
MessagePorts are alive in a page that is navigated away from. We can
always bfcache the page if we don't know of any "other sides" having
pinned their port. If we later detect that a port is being pinned, we
can indicate an error to the pinning side, and throw the bfcached page
out of the bfcache at that time. No synchronous IPC communication
needed. We do something very similar when the DOM of a bfcached page
is mutated.

As far as I can see, this is actually the most bfcache friendly
solution possible. I.e. it only tosses something out of the bfcache if
that page was expected to respond to a message. Not anytime a message
is sent or anytime a MessagePort exists.

If we want to worry about improving bfcaching beyond this proposal, I
think there are ways to do that. But I think that is orthogonal. For
example we've discussed adding an API which allows a page to say "I'm
aware that there are plugins on this page and that that would normally
prevent me from being bfcached. However I'm fine with being put in the
bfcache and those plugins being stopped when that happens, I can
deal". We could similarly add other APIs which indicates that the page
is able to handle recovering from actions that happen when a page is
being put in the bfcache, such as aborted network requests or aborted
message channels. But I don't think any of that work should block us
here. And i'm saying that as one of the implementors of the only
bfcaching browser as far as I know.

However I'm very open to discussing other syntaxes than the one in
[1]. For example I agree that pin()/unpin() are not the most
descriptive names. For example awaitAnswer() and answerReceived()
might be more understandable. Or of course totally different syntaxes
as long as they support the same use cases, and as long as convincing
technical arguments are presented.

>> I actually think that in Gecko won't be interested in implementing the
>> current spec for the close event since it won't solve our use case if
>> the other side happens to crash before we manage to register an onclose
>> handler.  The proposal which we're currently interested in implementing
>> is something along the lines of <
>> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/041250.html>.
>
> The problem with an elaborate proposals such as this one is that in UAs
> that never need to worry about this (e.g. because they are single-process,
> or they are desktop UAs that don't need to worry about a kill-happy OOM
> handler in the kernel and that are stable enough that they crash
> sufficiently rarely that they don't care to worry about this), the API is
> something that still needs to be implemented, even if it's a no-op, and so
> the more complicated the API the more wasted work it is.

Are there any UAs that have indicated that they feel stable enough
that they don't worry about crashes?

Additionally, any UA would need to worry about navigations as far as I know.

And note that navigations can't be handled by simply sending a message
in the onunload handler. That strategy doesn't work in dedicated
workers. And even if we add onunload to workers that doesn't help
long-running worker scripts.

Finally, has any implementation indicated that the proposal in [1] is
too burdensome to implement? If they have that of course changes the
discussion dramatically here. But I'm reluctant to guess about what
implementations will or won't implement. I'd rather ask them.

[1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/041250.html

/ Jonas