Re: [w3c/ServiceWorker] Should update() always reject if there is an installing worker? (#1429)

asutherland left a comment (w3c/ServiceWorker#1429)

Merging update() works for Firefox (and we can change our impl).

For the spec, is the idea that we would go further than the `lastJob` coalescing of [schedule job](https://w3c.github.io/ServiceWorker/#schedule-job-algorithm) and just merge with the (inductively) only update in the job queue if there is one and the job promise has not yet settled?

Since  [update()](https://w3c.github.io/ServiceWorker/#service-worker-registration-update) latches the newestWorker's script URL when it's called and the [update job algorithm](https://w3c.github.io/ServiceWorker/#update) rejects if the latched script URL does not match with the current newestWorker's state, it already is the case that enqueueing an update job that follows a register that isn't roughly an update will fail, likewise with unregister, so it seems reasonable to only support having one in the queue.  (Although I suppose you could have an interesting sequence of "update, unregister, register, update" where the same script URL is used for the register as existed before, and then that would be observable.)


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

Message ID: <w3c/ServiceWorker/issues/1429/5297227000@github.com>