Chrome: serviceWorker.ready() resolves before service worker is active after unregistering
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 3.6k
- Forks
- 324
- Avg merge
- 14d 22h
- Merged PRs (30d)
- 1
Description
This seems like this issue: https://github.com/w3c/ServiceWorker/issues/1139 but I am wondering why I only see this error on Chrome?
My scenario is this:
I click a button to register which does the following:
navigator.serviceWorker.register('./sw.js', { scope: './' }).then(...)
navigator.serviceWorker.ready.then(registration => {
registration.pushManager.subscribe...
....
}
Then I later click a button to unregister which does the following:
navigator.serviceWorker.getRegistrations().then(registrations => {
for (let registration of registrations) {
registeration.unregister()
}
})
Then, I re-click the button to register. But this time the the .ready() resolves before the .register() resolves leading to an error when subscribing for push (no active service worker). No matter how many times I click the button register, I keep getting the Subscription error even though the first time it activates the service worker...
When I tried this same scenario on Firefox, it worked as expected. If it is a bug on Chrome, is there any workaround I could do to wait until the registration is ready before subscribing?
EDIT: It seems like Firefox the behaviour is similar on firefox, but for some reason on Firefox the pushManager subscription is able to see the active service worker, but not on chrome.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the unregister and re-register sequence using navigator.serviceWorker.register, ready, getRegistrations, unregister, and pushManager.subscribe. Compare the observed behavior with the linked W3C issue and the Firefox result; done would require a confirmed explanation, specification change, or documented workaround.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- web-dev
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100