Re: [ServiceWorker] Race when registering multiple service workers for the same scope (#783)

I basically don't want to break any behavior that Blink implemented in conformance to the current spec so far. But I'm willing to refine the algorithms for simpler reasoning and the expected behavior if both Blink and Gecko agree.

Here's the outline of the refinement (if agreed) based on what's suggested:
- Q: A job queue
- J: A job: fetch a script and make it get through to .waiting (i.e. **Update to Install**). There are two types of jobs: 1) Jr: register job and 2) Ju: update job.

- Jobs are entirely serialized in Q.

- Activate is not serialized and can just be invoked in parallel. It basically makes the current .waiting to .active. (It simply returns when .waiting is null.)
(* I don't think it's reasonable to put Active in the single unit of a job serialization as triggering Active is indeterministic.)

- A update job (Ju) can't be inserted in Q if Q isn't emtpy. Currently, Soft Update doesn't insert Ju in Q in this case, but register.update() does. That inserted update job makes the current .installing a redundant and go ahead with its own Update/Install steps. <-- I'd like to know Chrome's position on this.

- Unregister is not serialized and can just be invoked in parallel. It basically sets the uninstalling flag. When no client is using the registration, the UA clears it out right away; otherwise, the last client unload will do.

- When the unistalling flag is set, an update attempt just returns not scheduling an update job (Ju).
- When the unistalling flag is set, a register attempt unsets the flag and go ahead with scheduling a register job (Jr).

@wanderview @mattto Based on the discussion here, I'll try to refine the spec algorithms.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/783#issuecomment-161857109