1566578 - Resolution of a ready promise acquired before registering a new Service Worker may race

Status: NEW

(Core :: DOM: Service Workers, defect, P3)

Description

[Perry Jiang [:perry] [no longer employee, use ni?]]

This issue only applies to parent-intercept mode. Assume there are no existing Service Worker registrations. Consider:

const readyPromise = navigator.serviceWorker.ready;
const registration = await navigator.serviceWorker.register('./sw.js');
const shouldBeSameRegistration = await readyPromise;
assert(registration.active.scriptURL === shouldBeSameRegistration.active.scriptURL);

registration.active could be null (when it should be non-null) if this is what's going on:

1. The install algorithm runs in the parent process, initiating the resolution of the promise returned by navigator.serviceWorker.register.
2. In parallel,

• In the content process, a ServiceWorkerRegistration object is created (as the resolve value of the register promise). This object begins setting up its actors to subscribe to the corresponding ServiceWorkerRegistrationInfo in the parent process for state updates. This process involves an asynchronous IPC call, so when the register promise resolves, it is not guaranteed that the resulting ServiceWorkerRegistration is in sync with the parent process data.
• In the parent process, the worker transitions to the activate state, initiating the resolution of the promise returned by navigator.serviceWorker.ready. The calls to do this propagate to the content process before the ServiceWorkerRegistration in the previous step can subscribe and be up-to-date with its ServiceWorkerRegistraitonInfo.

3. The ready promise resolves, with an up-to-date state, so shouldBeSameRegistration.active is non-null, while registration.active is null (registration is not up-to-date).

To solve this, before resolving the ready promise corresponding to a given ServiceWorkerRegistrationInfo, we need to be aware of all associated ServiceWorkerRegistrations and ensure that they're up-to-date. Specifically, the spec's "Update Registration State" algorithm states

Let registrationObjects be an array containing all the ServiceWorkerRegistration objects associated with registration.

and it seems that we don't always have all these objects when we need them.