Is this the same as #1270? (I was just looking at this yesterday as well.)

I think your reading of the spec is correct.

For the "Clear Registration" test, are you talking about registration-service-worker-attributes.https.html? I suspect the comment there was written for an older version of the spec:

          // According to spec, Clear Registration runs Update State which is
          // immediately followed by setting active to null, which means by the
          // time the event loop turns and the Promise for statechange is
          // resolved, this will be gone.

(And yea I think can dupe this to #1270 or vice versa)

I think we should reverse the order of updating in the spec. The registration should be updated before we fire the statechange event, IMO.

Yes, I tend to think that when the worker is "redundant" it should be dead and gone from the registration. I don't know if there's a particular reason the spec ended up with this other order. It seems like the intent was "redundant" means the worker is "going away" based on the non-normative note here: https://w3c.github.io/ServiceWorker/#ref-for-dom-serviceworkerstate-redundant%E2%91%A0

The spec originally didn't have any task queuing to update the DOM objects. I think the order just got reversed on this one call site when that was added.

Well there are at least 2 call sites, Clear and Install (when it fails).

I'm OK with changing the spec then, especially since it sounds like this order wasn't intended.

I've seen what looks like the same root issue, where registration.active.state === 'redundant'. I've been able to reproduce this issue intermittently in headless chrome service worker tests.

As a general rule, we should ensure that the following properties are updated:

• installing/waiting/active on registration objects.
• state on service worker objects.
• controller on navigator.serviceWorker.

…before notifying the developer that any of those things have changed. Our current notifications are:

• updatefound event on registration objects.
• statechange event on service worker objects.
• navigator.serviceWorker.ready.
• controllerchange event on navigator.serviceWorker.
• install, activate event on the service worker global.

I'll review the spec for this, and ideally come up with a system that enforces the above.

Some research on what the spec says vs what browsers do:

One worker, going through the steps

When I say "reg: null, null, worker" I mean, on the registration, installing was null, waiting was null, active was a worker:

Chrome, Firefox and Safari all behave the same as the spec.

An new active worker

This is where things are different. I'm going to compare:

• Current spec
• Central algorithm for updating service worker state and registrations #1416 - this is my ideal, which tries to make all related object changes before firing events.
• Update order #1436 - a much smaller change that updates registration objects before firing
• Browsers.

In this test, worker1 is active, worker2 is waiting. worker2 becomes active, worker1 becomes redundant.

Chrome and Safari match the current spec, but that means a redundant worker is seen within the registration.

Firefox gets the order wrong.

A new waiting worker

In this test, worker1 is active, worker2 is waiting, worker3 is installing. Then, worker3 becomes waiting, worker 2 becomes redundant.

The story is the same as above.

Clear registration

In this test, worker1 is active, worker2 is waiting. The registration is unregistered.

Here the browsers break from the spec (I think they're following a test) and update the registration before firing any statechange events. Firefox goes further and updates both workers before firing any events.

I think our options are:

• Spec what Chrome and Safari are doing.
  • In some cases the registration will be updated before the statechange events fire, sometimes they won't.
  • Within a transaction, 'statechange' happens on the youngest worker first.
  • Within a transaction, worker.state is updated just before that worker's 'statechange' (meaning other workers will be showing old values)
• Update order #1436
  • For a transaction, update the registration before firing any 'statechange' events.
  • Within a transaction, 'statechange' happens on the youngest worker first.
  • Within a transaction, worker.state is updated just before that worker's 'statechange' (meaning other workers will be showing old values).
• Central algorithm for updating service worker state and registrations #1416
  • For a transaction, update the registration before firing any 'statechange' events.
  • For a transaction, update all worker.state properties before firing any 'statechange' events.
  • Within a transaction, 'statechange' happens on the youngest worker first.