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

Re: [whatwg] onclose events for MessagePort

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 9 Oct 2013 23:58:52 -0700
Message-ID: <CA+c2ei8U4N_twivGsdZ72n2h6LQ2j1k-woJU1RTwf6PL4EzOwA@mail.gmail.com>
To: Ehsan Akhgari <ehsan@mozilla.com>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, Gene Lian <clian@mozilla.com>
On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari <ehsan@mozilla.com> wrote:
> OK, so I gave this some thought and I and Olli managed to convince each
> other that finding a solution to the problem of dispatching a generic
> onclose event is impossible since there is no deterministic point in time
> before a worker is GCed when we know that it will be GCed soon.
>
> So with that behind us, how about we add an explicit event to be fired when
> the other side of a message channel gets destroyed in a catastrophic way
> which is not observable from the web content code running on that side, such
> as a process crash for example?  The basic idea behind why this more
> restricted proposal is useful is that barring the catastrophic failure case,
> applications can detect the other cases why further communication may be
> impossible (such as navigating away from the page) themselves and notify the
> other side of the channel as desired -- it is only the catastrophic
> termination case which is not detectable from content script.
>
> How about we add another event named "channeldropped" (pending bikeshedding)
> which is fired on a message port if the owner global context of its
> entangled port is terminated in a catastrophic way?  Needless to say, the
> event will be queued asynchronously with the termination of the other side,
> and it will not be affected by garbage collection.

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?

/ Jonas

> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
> On Tue, Oct 1, 2013 at 6:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> > On 10/1/13 2:11 PM, Ian Hickson wrote:
>> >>
>> >> How often do we expect two tabs to be talking to each other though?
>> >
>> > Or a page to an out-of-process subframe?
>>
>> Or an out-of-process worker. I would think that in Chrome
>> SharedWorkers can come from a separate process, though that might
>> change if/when chrome switches to out-of-process iframes.
>>
>> / Jonas
>
>
Received on Thursday, 10 October 2013 06:59:47 UTC

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