Re: [ServiceWorker] Install algorithm step 14 should clear waiting worker before updating state to redundant (#851)

So, I think since we "queue a task" to fire the statechange event, then this all works fine for DOM objects on the main thread.  I think there is a problem for DOM objects on workers, though.

ServiceWorker DOM objects exposed on a worker thread are spec'd to access attributes like `.installing` like this:

> Let waitingWorker be the ServiceWorker object that represents the service worker registration’s waiting worker.

This seems to have immediate and synchronous access to the `registration's waiting worker`.

When we queue a task to fire the statechange event on the worker thread, however, it may fire before the `registration's waiting worker` is updated.  So worker threads may see an inconsistent view of ServiceWorker and ServiceWorkerRegistration DOM object state.

Now, if the spec said to queue a task to update the ServiceWorkerRegistration DOM object on the worker thread, then we could rely on the "queue a task" language to order things correctly for the worker thread.

Also, all of this would be much easier to understand if we had a note for each Update State clarifying what we expect the ServiceWorkerRegistration and ServiceWorker info objects to look like when the event happens.  Its hard to ensure both window and worker threads see the same state currently.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/851#issuecomment-199324636