[whatwg] onclose events for MessagePort

[Ehsan Akhgari]

On Thu, Oct 10, 2013 at 3:11 AM, Andrew Wilson <atwilson at google.com> wrote:

>
>
> On Thu, Oct 10, 2013 at 8:58 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>>
>> I could see the GC case not being solvable.
>>
>> But is there a reason that we couldn't also fire the event if the
>> other side is forcefully terminated through a navigation or a
>> Worker.terminate() call?
>>
>
> I still have the concerns I expressed earlier about figuring out who the
> owner is of the port in the case where you've passed a reference around to
> multiple contexts. What does "other side is forcefully terminated" mean in
> the case where you may have multiple iframes with references to the same
> port?
>

Sorry for the vague language.  The other side is the "owner" of the port on
the other side of the MessageChannel.


> i.e. if my iframe does this:
>
> channel = new MessageChannel();
> window.parent.port = channel.port1;
> sharedWorker.port.postMessage("port", [channel.port2]);
> window.location.href = "<some other url>"
>

Here, the owner of port1 is window, and the owner of port2 is the shared
worker's global context.  So, port2 will receive a "channeldropped" message
if the current browsing context crashes (or when the navigation occurs in
the model that Jonas is suggesting.)


> What happens? Does the sharedWorker get channeldropped on it's cloned
> port? I suspect this would be confusing to developers, who might otherwise
> expect that merely handing a reference to port to its same-origin parent
> would be sufficient to keep it alive.
>

Why would they expect that?  Storing a reference to a port object on a
parent doesn't change the owner of the port.  (I agree that this can be a
bit confusing if authors are not familiar with MessagePorts, but this is
part of the semantics of the ports as currently specified, and I don't
think the channeldropped event proposal changes the amount of confusion
here.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>