[whatwg] onclose events for MessagePort

[Ehsan Akhgari]

On Thu, Oct 10, 2013 at 4:48 AM, Simon Pieters <simonp at opera.com> wrote:

> On Thu, 10 Oct 2013 08:58:52 +0200, 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?
>>
>
> Does navigation disentangle ports? I don't think it necessarily does, at
> least per spec.


The current spec doesn't mention what happens in the case of navigation in
the owner for a port as far as I can tell.  But I consider that a bug in
the spec -- navigation _should_ disentangle ports.

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