[w3c/ServiceWorker] Should the worker be removed from the registration *before* its state is set to "redundant"? (#1273)

While investigating some web-platform-tests failures on WebKit, a possible difference in behavior between Firefox/Chrome and the specification.

For example, when the install step fails, the spec says:
If installFailed is true, then:
1. Run the Update Worker State algorithm passing registration’s installing worker and redundant as the arguments.
2. Run the Update Registration State algorithm passing registration, "installing" and null as the arguments.

Notice the order, we first set the worker state to redundant, then we set the registration's installing worker to null. This means that when the statechange event is fired on this worker, registration.installing is not set to null yet (according to my understanding of the spec).

However, local testing shows that in Firefox and Chrome, registration.installing already returns null when the statechange event is fired at the worker (with state being redundant).

Should the specification be updated to match the behavior of browsers? Or did I misinterpret the specification?

I believe there is a similar issue in the "Clear Registration" algorithm. There is a WPT test that seems to assume that when clearing the registration, and the waiting worker becomes redundant, then all the registration's installing/waiting/active worker should be null. This test seems to pass in Chrome/Firefox.
However, my understanding is that the spec says:
1. Set installing worker state to redundant & schedule a task to fire statechange event at worker
2. Schedule a task to update ServiceWorkerRegistration(s) installing worker to null
3. Set waiting worker state to redundant & schedule a task to fire statechange event at worker
4. Schedule a task to update ServiceWorkerRegistration(s) waiting worker to null
5. Set active worker state to redundant & schedule a task to fire statechange event at worker
6. Schedule a task to update ServiceWorkerRegistration(s) active worker to null

So when the statechange is fired at the waiting worker, based on the spec, I would not expect registration.waiting / registration.active to become null right away. Instead, I would have expected registration.waiting to return null after 1 event loop iteration, and  registration.active even later.

-- 
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/1273