Re: [w3c/ServiceWorker] Central algorithm for updating service worker state and registrations (#1416)

The original issue (https://github.com/w3c/ServiceWorker/issues/1273) is about consistency of state, so I guess that's the important bit. 

https://w3c.github.io/ServiceWorker/#installation-algorithm steps 17 & 18 leave the possibility of JavaScript seeing the same worker in `.installing` and `.waiting`.

There are many places where the a worker becomes redundant, but it's still in `.installing`/`.waiting`/`.active`.

https://w3c.github.io/ServiceWorker/#activation-algorithm steps 3 & 4 leaves the possibility of JavaScript seeing the same worker in `.waiting` and `.active`.

Even if we swap things around (as originally proposed in https://github.com/w3c/ServiceWorker/issues/1273), you can still end up with JavaScript seeing a worker in `.waiting` that has a state of `installing`.

If objects are updating across multiple tasks, we're always going to have this problem.

How about:

1. For a single update (like a worker being promoted to active, and the current active worker becoming redundant), we update all related JS objects across globals that share the event loop.
1. Related events then fire, which may be split across tasks, as long as they fire before the next state update.

@mattto 

> Chrome also doesn't have a good system yet of changing all the JS objects first and then firing the events. Not really sure yet how difficult it would be to change these.

I can't think of a better way to achieve consistency here. Is it _too difficult_?

@wanderview @asutherland Do you have a feel about this in terms of Mozilla's code base.

@youennf @cdumez Do you have feelings on this in terms of WebKit?

-- 
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/pull/1416#issuecomment-499510939