[whatwg] onclose events for MessagePort

[Jonas Sicking]

On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari <ehsan at 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 at sicking.cc> wrote:
>>
>> On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky <bzbarsky at 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
>
>