-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide an easier way to listen for waiting/activated/redundant Service Workers #1247
Comments
Alerting users of a waiting service worker might look like this: Combined with #1016, that means that showing a "please refresh" banner could work like this: function alertUser(reg) {
// don't use confirm in production; this is just an example
if (confirm('Refresh now?')) reg.waiting.skipWaiting();
}
if (reg.waiting) alertUser(reg);
reg.addEventListener('statechange', function(e) {
if (e.target.state === 'installed') {
alertUser(reg);
} else if (e.target.state === 'activated') {
window.location.reload();
}
}); |
@dfabulich I like your suggestion. I can't believe nobody has been assigned to fix this! |
A promise doesn't really work in this case, as many service workers can pass through the waiting phase during the life of a page. |
In fact, this issue was originally @jakearchibald's idea, in a comment on #1222. As far as I can tell, nobody has had anything bad to say about it. I might have preferred #1222, but since that approach seems to be dead in the water, this is still a big improvement over the status quo. |
+1 for @dfabulich prolyfil idea. 3 years old and still needed IMO. |
Breaking off from #1222.
ServiceWorker.state
has five states:installing
,installed
(waiting),activating
,activated
, andredundant
.Today, client-side code can listen for
installing
SWs withServiceWorkerRegistration.onupdatefound
;activating
can be tracked withnavigator.serviceWorker.oncontrollerchange
.The other three states are annoying to listen for.
That's too bad, because lots of users want to track the
installed
state so they can show a refresh banner. Furthermore, some users apparently want to trackredundant
SWs for error handling. And it turns out that refreshing the page as the page is activating is slightly too soon; you should wait for theactivated
event, to avoid a minor performance bug.In #1222 we observed that awaiting these states would be way easier if
statechange
bubbled up to the registration, so users who wanted to track theredundant
andactivated
states would just do this:The text was updated successfully, but these errors were encountered: