- From: Ben Kelly <notifications@github.com>
- Date: Thu, 21 Apr 2016 06:55:51 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc:
- Message-ID: <slightlyoff/ServiceWorker/issues/886@github.com>
I'd like to tentatively propose that we fire a `clientcontrolled` event on the ServiceWorkerGlobalScope when that worker begins controlling a client. There could also be a `clientuncontrolled` event, but that is less important to me at the moment. This could enable service workers to maintain and track state more specifically than they can do today. Right now SWs can infer which clients are going to be controlled from FetchEvent, but its really an approximation. Some documents will fail to load or be closed. Exposing these events would provide better tracking. My real reason for suggesting this, though, is to handle a corner case with bfcache. I realize firefox might be the only browser to implement bfcache, so this may not be a strong argument. But consider the following situation: 1. Document A is controlled by SW X. 2. User navigates the window and A goes into the bfcache. A also becomes uncontrolled at this point so history items don't block updates, etc. 3. SW X then does a Clients.matchAll() and see A is gone. It cleans up Cache objects and state A was using. 4. User clicks the back button and A comes back out of the bfcache. Our current plan is to make it controlled again with the same client ID. 5. SW X does a Clients.matchAll() and suddenly sees A again, but it never saw a FetchEvent. SW becomes confused and goes to cry in the corner. Some options we considered, but currently don't like: * Disable bfcache for documents that are controlled. This would effectively disable bfcache for huge swaths of the internet; Facebook, Pinterest, etc. * Expose documents in bfcache to Clients.matchAll(). This would be super confusing as the list just grows as the user navigates. Also, things like Client.focus() would not make sense. * Don't re-control documents when they come out of bfcache. This would make it look like a new uncontrolled client appeared which is normally possible via a hard refresh. This would expose a difference between browsers, though, because history.back() would result in a controlled document in chrome, but not firefox. I'm open to suggestions, but the `clientcontrolled` event would have wider application and would let the SW behave sensibly to this case. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/issues/886
Received on Thursday, 21 April 2016 13:56:19 UTC