This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://dev.w3.org/html5/workers/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Referrer: Comment: It seems that there is no way to inform a shared worker that a document connected to it is closed. In the example in section "Shared state using a shared worker", the object "viewers" will never be shrinked before the whole worker is closed. Base on the reason above, I propose that an inverse event of connect, say disconnect, should be added into SharedWorkerGlobalScope, so that the worker has a chance to clean up any information related to the closed document. In addition, I propose that SharedWorkerGlobalScope could further provide a method for broadcasting messages to all alive ports so that authors need not manipulate a list of the ports themselves. Posted from: 14.203.227.181 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0
When would you fire the event? (Consider the case of a page where the user navigates away from the page, then navigates back, and the page is in the bfcache the whole time, for example.)
(In reply to Ian 'Hixie' Hickson from comment #1) > When would you fire the event? > > (Consider the case of a page where the user navigates away from the page, > then navigates back, and the page is in the bfcache the whole time, for > example.) Maybe it could first disconnect and then redo the connect. I propose that it is always fired when user leaves the page. Even if you always keep the page in the bfcache, the worker cannot communicate with the page until it becomes the current one, can it? If this is a problem, maybe we can create an extra 'reconnect' event for such case, so that worker and page knows when and how to restore the connection. BTW, what is the strategy applied to the worker's lifetime? If all pages referenced it is only in bfcache, will the worker still exist? If we do not have such event, there will likely be a memory leak in the worker side as for some site, pages may be opened and closed frequently. If the author tries to solve the problem, he may create a custom mechanism like heartbeats, which is even more complex and unreliable considering the case you mentioned.
The problem is that most browsers don't have a bfcache, and authors are often likely to forget to test for the bfcache, and so many pages wouldn't support the reconnect event. So now instead of memory leaks, we've broken pages. I don't know what to do about this. (There's been discussions about it in the WHATWG list as well, where we failed to come up with a good solution.)
(In reply to Ian 'Hixie' Hickson from comment #3) > The problem is that most browsers don't have a bfcache, and authors are > often likely to forget to test for the bfcache, and so many pages wouldn't > support the reconnect event. So now instead of memory leaks, we've broken > pages. If you provides, they will have a higher chance to be aware of it. Since leaving page always causes connection to be at least paused, the page could always have chance to be broken without special attention (or do you think js should be executed normally even if the page has been navigated away?) I don't think the fact that there is no 'disconnect' or 'reconnect' event could help authors not to make these mistakes. > I don't know what to do about this. (There's been discussions about it in > the WHATWG list as well, where we failed to come up with a good solution.) Would you mind providing the URL of the thread about this?
The messages in this query (dating from ~Oct 2013 to ~Feb 2014) are the ones I was thinking about: http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=subject&hdr-1-query=onclose+events+for+MessagePort&index-grp=Public_FULL&index-type=t&type-index=public-whatwg-archive
This needs a proposal before it can make further progress, really.