- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 9 Oct 2013 23:58:52 -0700
- 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