[whatwg] onclose events for MessagePort

[Ian Hickson]

On Mon, 3 Feb 2014, Jonas Sicking wrote:
> 
> I agree that being able to prevent an object from getting GCed isn't 
> great, however any solution in this space is going to require the UA to 
> retain a bit more memory. The reason that we need to retain the 
> MessagePort object in the solutions discussed so far is that we've tried 
> to fire the event on the MessagePort object itself. If we instead fired 
> an event on the global indicating "the other side has gone away", then a 
> MessagePort doesn't need to be retained.
> 
> However such a solution requires a different way to identify which 
> communication channel was severed. We could allow naming ports and then 
> the name of the port would be included in the "lost connection to an 
> other side". Of course, that requires keeping that name in memory which 
> is arguably as leaky. Or we could come up with numeric port identifiers, 
> in which case less memory is "leaked".

I think this would just result in authors keeping track of the ports in an 
index, which would prevent them from being GC'ed, which defeats the point.


> The bfcache issue is solvable as discussed.
> [...] 
> As soon as any of them can't deal with bfcache the page won't be
> bfcached.

I don't think "solvable" is the same as "design an API that basically 
guarantees that within a decade most of the Web won't be bfcached".


> I'm happy to experiment. In the meantime I would ask that 
> MessagePort.onerror is removed as I don't think any browser vendor has 
> expressed a desire to implement.

Done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'