Re: [whatwg] onclose events for MessagePort

On Thu, 17 Oct 2013, Ehsan Akhgari wrote:
> On Tue, Oct 15, 2013 at 5:23 AM, Simon Pieters <simonp@opera.com> wrote:
> > On Thu, 10 Oct 2013 17:22:32 +0200, Ehsan Akhgari <ehsan@mozilla.com> 
> > wrote:
> >>
> >> The current spec doesn't mention what happens in the case of 
> >> navigation in the owner for a port as far as I can tell.  But I 
> >> consider that a bug in the spec -- navigation _should_ disentangle 
> >> ports.
> >
> > Why?
> >
> > How would it work? If the port gets disentangled, it means the 
> > document has to set the salvegeable flag to false, so that navigating 
> > back doesn't put the document in a broken state. Do browsers do that? 
> > Is it the best thing to do?
> >
> > What if another document also has a reference to the port, does it 
> > still get disentangled when the owner gets navigated?
> 
> Yeah, I think I was wrong to assume that navigation disentangles the 
> ports...

Navigating doesn't disentangle the ports, for the reason Simon describes.

However, it's not quite clear what it _does_ do. The spec is actually 
underspecified here.

Consider these three scenarios:

A. Page Alpha opens a shared worker, and they communicate using a pair of 
MessagePorts. Alpha is navigated away, going to Beta in a different 
origin. Later, the user hits back, and since Alpha is still in the 
bfcache, the shared worker can still communicate, and the messages that 
were sent while Alpha was away get delivered.

B. Page Gamma is has an iframe. In that iframe, there's page Alpha, which 
opens a shared worker, and they communicate using a pair of MessagePorts. 
Alpha is navigated away, leading the iframe to Beta in a different origin. 
Later, the user hits back, and since Alpha is still in the bfcache, the 
shared worker can still communicate, and the messages that were sent while 
Alpha was away get delivered.

C. Page Gamma is has an iframe. In that iframe, there's page Alpha, which 
opens a shared worker, and they communicate using a pair of MessagePorts. 
Alpha then passes a reference to the port to Gamma. Then, Alpha is 
navigated away, leading the iframe to Beta in a different origin. Gamma 
and the shared worker can communicate.

A and C are mutually exclusive. Either the port's messages get delivered 
while Alpha is away, or they don't. Or there's a third option, actually, 
which is to make it dependent on the listeners. We could do that I guess, 
but it's not clear to me how that would work -- would you just pause the 
port's message delivery while it has no listeners whose script's document 
is active? (Delivering events to listeners whose script's document is not 
fully active causes the events to be dropped on the floor. Queuing a task 
to deliver an event, however, if that task is associated with that 
inactive document, results in the task being queued waiting for the doc to 
return to active status.)

The spec right now doesn't say which of these should happen. I happen to 
be editing the text for this right now for unrelated reasons (refactoring 
how scripts are described) so if anyone has an opinion on how this should 
work, now's a good time to let me know.

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

Received on Tuesday, 29 October 2013 23:45:53 UTC