Re: [whatwg] onclose events for MessagePort

On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking <jonas@sicking.cc> wrote:

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

Does navigation disentangle ports? I don't think it necessarily does, at  
least per spec.

-- 
Simon Pieters
Opera Software

Received on Thursday, 10 October 2013 08:48:47 UTC