[whatwg] onclose events for MessagePort

[Ehsan Akhgari]

On Thu, Oct 10, 2013 at 2:58 AM, Jonas Sicking <jonas at sicking.cc> wrote:

> 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?


The reason I did not extend this to navigation and Worker.terminate() is
that at least in theory the authors should be able to detect those in their
application and use postMessage() to communicate that information if
desired (assuming that you can handle window.onunload and have control over
the code calling terminate(), respectively.)

Although perhaps my argument is a bit weaker about terminate() than
navigation.

Do you see a good reason why we should not leave those cases to authors?

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



>
> > --
> > 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
> >
> >
>