Serviceworker lifecycle question

[Jacob WANG]

Hi,

I am working on a project that uses the awesome serviceworker! But I meet with some race condition when I try to register a new service worker.

After some investigation, I find navigator.serviceworker.ready does not really reflect the correct status of the controlled page. So I turned to use event-based method: controllerchange. And I want to make sure fetch event is fired after controllerchange.

From online resource:

"The oncontrollerchange property of the ServiceWorkerContainer interface is an event handler fired whenever a controllerchange event occurs — when the document's associated ServiceWorkerRegistration acquires a new ServiceWorkerRegistration.active worker."

https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/oncontrollerchange

And

"A service worker won't receive events like fetch and push until it successfully finishes installing and becomes "active"."

https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle

I guess it is the case as I mentioned above. Could you please tell me whether controllerchange is always fired before the service worker is active (i.e. before fetch event?) when installing a new service worker?

Thanks!

Jacob

[Matt Falkenhagen]

bcc: chromium-dev

cc: service-worker-discuss

Can you elaborate with sample code what you're trying to do?

navigator.serviceWorker.ready resolves there's an active service worker for the document URL. It doesn't necessarily mean there is a service worker controlling the current document. Notably, if the document registered a new service worker, then .ready will resolve once the worker is active but the document won't be controlled until you reload (or use claim()).

controllerchange is only fired if skipWaiting() or claim() was used. It's fired when the document's controller changes (it may go from no controller to a controller, or from one controller to another controller).

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/f144df03-6d62-4e8d-84d1-be06cd423c4e%40chromium.org.

[Stefan Zager]

I have noticed similar behavior while developing some service worker code; reproduction steps:

- open an incognito window

- load a client page that installs a SW that has a bug which results in an uncaught exception

- In chrome://serviceworker-internals, 'Stop' and 'Unregister' the SW

- Fix the bug

- Reload the client page

On second load, the SW gets reinstalled, but the controllerchange event never fires in the client page.

I haven't filed a bug yet because I'm a bit busy, and I want to see if I can reduce it any further.

--

[Jacob WANG]

Thanks Stefan! Your step of reproducing the issue is similar to mine.

Jacob

[Matt Falkenhagen]

bcc: chromium-dev, cc: service-worker-discuss

As described above, the second load isn't expected to get a controllerchange unless the service worker calls claim() after it activates.

At the time second load begins, there is no registration, so it loads without an associated service worker registration.

Once the service worker activates, navigator.serviceWorker.ready should resolve, but navigator.serviceWorker.controller should remain null.

If at that time service worker calls claim(), the document should get the controllerchange event and navigator.serviceWorker.controller should be the active service worker.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BcnNbgYZF%2BihFq5XPzdAZ0tV%3D4ArMV5WTZSAPUo7_zjXYOSYg%40mail.gmail.com.