Bugzilla

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

```js
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 `ServiceWorkerRegistration`s and ensure that they're up-to-date.

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

```js
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 `ServiceWorkerRegistration`s 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__.

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

```js
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 `ServiceWorkerRegistration`s 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.