- From: Ben Kelly <notifications@github.com>
- Date: Fri, 21 Oct 2016 07:59:42 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/993/255400498@github.com>
> The waiting service worker activates by default when you close the last tab, even if you immediately click a bookmark to re-open the site. In my view, that's exactly what refreshing is: it's a navigation away, followed immediately by a navigation back to the current page. This isn't really accurate. The browser starts loading the next page, but doesn't tear down the current page until that new request completes. So when the navigation FetchEvent fires the page is still being shown to the user. > …the idea that the navigation would be delayed until the waiting worker activates, so the navigation request would go through the new worker. I don't think you will have a waiting worker at this point. Both chrome and firefox wait to perform the update check until after the navigation load event. I guess you could manually call `update` and then wait for the resulting promise to resolve. At that point you should have an `installing` worker you could wait on. Given that `update()` must be called to get the SW before the refresh navigation I think pages should probably just build their own "check for updates" and "update found, click to reload" buttons. I suppose devtools could also have those buttons for the site. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/993#issuecomment-255400498
Received on Friday, 21 October 2016 15:00:13 UTC