ServiceWorker does not unregister on localhost without query component in scriptURL

[guest271314]

This stackoverflow question Cache Service worker for localhost can't be remove and unregistered describes the issue where when URL is localhost and unregister() is called the ServiceWorker is not unregistered.

This appears to be a Chromium/Chrome bug. The behaviour is not reproduced on Firefox 95. (Chromium authors banned me bugs.chromium else I would file this there).

The workaround I am currently using is to register the ServiceWorker with a query component. Then the ServiceWorker will be unregistered. 

for (const registration of await navigator.serviceWorker.getRegistrations()) {
  try {    
    await registration.unregister();    
  } catch (e) {
    console.error(e);
  }
}
// without including query component the above will not unregister the ServiceWorker
const sw = await navigator.serviceWorker.register(`sw.js?${new Date().getTime()}`, {
  scope: './',
});

[Yannic Bonenberger]

This is because Chrome still resurrects service workers: https://bugs.chromium.org/p/chromium/issues/detail?id=971571 https://github.com/w3c/ServiceWorker/pull/1415

registration.unregister() may only "mark a service worker as deleted". That is because the unregistered service worker could still be the controller for a page, and the worker will stay around until that page is closed or another service worker claims to be its controller. Resurrection is (was) a feature that, if you unregister a service worker and then register the same worker again while the old one is still around, it won't actually register a new service worker but rather resurrect the unregistered worker.

On a general note, I'd recommend to always use a unique name for the service worker (e.g. the hash of the JS file), which works around this bug in Chrome and also ensures that you don't run into caching issues.

[guest271314]

Interesting.

> or another service worker claims to be its controller

How is that achieved?

>  it won't actually register a new service worker but rather resurrect the unregistered worker.

Can you explain "resurrect" in this case?

> On a general note, I'd recommend to always use a unique name for the service worker (e.g. the hash of the JS file), which works around this bug in Chrome and also ensures that you don't run into caching issues.

How do we name a ServiceWorker and implement the pattern that avoids the issue?

(For context I encountered the issue on localhost while testing implementation of persistent ServiceWorker (on localhost) to workaround 5 minute before becoming inactive restriction on arbitrary web pages and using MV3 extension ServiceWorkers https://crbug.com/1152255. I will publish the working code (Chromium 99 web pages and extensions; Firefox 95) later today or tomorrow on GitHub.)

Variable 'start' is defined in ServiceWorkerGlobalScope to verify persistence.

Firefox 95

Chromium 99