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

Re: [whatwg] onclose events for MessagePort

From: Andrew Wilson <atwilson@google.com>
Date: Wed, 2 Oct 2013 11:49:53 +0200
Message-ID: <CAArhhist8=3Dq_AvpLDK_OD6_KmuNaPg8zTzdv3poGvcapaUQw@mail.gmail.com>
To: olli@pettay.fi
Cc: whatwg <whatwg@lists.whatwg.org>, Ehsan Akhgari <ehsan@mozilla.com>
On Tue, Oct 1, 2013 at 7:01 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> I don't understand what "the lifetime of MessagePorts to the lifetime of
> their owner document"
> means in case of workers. And we sure want to delete MessagePort objects
> if nothing from JS side
> is keeping it, or the port it is connected to alive.

Definitely no, in the former case (nothing on JS side is keeping it) - we
definitely shouldn't fire a close event in that case since it exposes GC.

I think that it's pretty clear what the owner is in the case of workers -
the worker itself, which has a defined lifetime that is not necessarily
tied to the lifetime of any specific document.

I don't have any objections to adding some kind of close event to detect
cases where an owner goes away, but I agree we need to be careful about
what constitutes an "owner" and when precisely ownership is transferred, in
the cases like:

a) iframe creates a MessageChannel, posts port1 off to some SharedWorker,
then hands a reference to port2 off to a bunch of other iframes, or popup
windows, or whatever, then closes itself. At what point does a close event
get generated on port1? It seems like we have to fire the onclose after the
last window/iframe is destroyed, and it seems tricky to precisely track
when a window becomes a co-owner of a port (since we don't want to expose
GC specifics, we can't use reference chains to determine this).

b) iframe creates a port, posts it to another port's queue, then posts that
port to another window, we need to make sure we also transfer ownership of
all of the nested ports that are sitting in the various nested port queues.
I think the existing port cloning specification already handles this
ownership transfer, but it's worth keeping in mind as it further
complicates the implementation.

> -Olli
>> [1] https://www.w3.org/Bugs/**Public/show_bug.cgi?id=23327<https://www.w3.org/Bugs/Public/show_bug.cgi?id=23327>
>> Thanks!
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
Received on Wednesday, 2 October 2013 09:50:23 UTC

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