W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] onclose events for MessagePort

From: Ehsan Akhgari <ehsan@mozilla.com>
Date: Thu, 10 Oct 2013 11:20:50 -0400
Message-ID: <CANTur_5PaWN+1diLiQ5fV0j3qJQojqV9Ke09tiH5kxbduGvCVw@mail.gmail.com>
To: Andrew Wilson <atwilson@google.com>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>, Gene Lian <clian@mozilla.com>
On Thu, Oct 10, 2013 at 3:11 AM, Andrew Wilson <atwilson@google.com> wrote:

> On Thu, Oct 10, 2013 at 8:58 AM, Jonas Sicking <jonas@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

Received on Thursday, 10 October 2013 15:21:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:11 UTC