On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking <jo...@sicking.cc> wrote:
On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari <eh...@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?
Does navigation disentangle ports? I don't think it necessarily does, at
least per spec.
--
Simon Pieters
Opera Software
