So I believe the situation is this: - We lookup the registration in SWRP::InitOnMainThread via `swm->GetRegistration(mDescriptor.PrincipalInfo(), mDescriptor.Scope())` [https://searchfox.org/mozilla-central/rev/9df2ccc256fe54c314b34e52920471a0d04b283e/dom/serviceworkers/ServiceWorkerRegistrationProxy.cpp#80](here) - Note that we don't pass the id, just the principal and the scope. - The scope lookup is exact, the scope matching algorithm is not run. - If the lookup returns null, we do NS_ENSURE_TRUE_VOID which causes us to early return and trigger the MakeScopeExit() cleanup. - Then we assert the id is the one on the descriptor we created it from. A new registration has replaced the old registration for this to be the case. This either happens because of a [register() job](https://searchfox.org/mozilla-central/rev/9df2ccc256fe54c314b34e52920471a0d04b283e/dom/serviceworkers/ServiceWorkerRegisterJob.cpp#45) or in [LoadRegistration](https://searchfox.org/mozilla-central/rev/9df2ccc256fe54c314b34e52920471a0d04b283e/dom/serviceworkers/ServiceWorkerManager.cpp#1474) (which really shouldn't happen). So perhaps the most likely scenario is that the google news site has some logic in place that calls unregister() followed by register() and things are backlogged enough that this particular race happens.
Bug 1588357 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So I believe the situation is this: - We lookup the registration in SWRP::InitOnMainThread via `swm->GetRegistration(mDescriptor.PrincipalInfo(), mDescriptor.Scope())` [here](https://searchfox.org/mozilla-central/rev/9df2ccc256fe54c314b34e52920471a0d04b283e/dom/serviceworkers/ServiceWorkerRegistrationProxy.cpp#80) - Note that we don't pass the id, just the principal and the scope. - The scope lookup is exact, the scope matching algorithm is not run. - If the lookup returns null, we do NS_ENSURE_TRUE_VOID which causes us to early return and trigger the MakeScopeExit() cleanup. - Then we assert the id is the one on the descriptor we created it from. A new registration has replaced the old registration for this to be the case. This either happens because of a [register() job](https://searchfox.org/mozilla-central/rev/9df2ccc256fe54c314b34e52920471a0d04b283e/dom/serviceworkers/ServiceWorkerRegisterJob.cpp#45) or in [LoadRegistration](https://searchfox.org/mozilla-central/rev/9df2ccc256fe54c314b34e52920471a0d04b283e/dom/serviceworkers/ServiceWorkerManager.cpp#1474) (which really shouldn't happen). So perhaps the most likely scenario is that the google news site has some logic in place that calls unregister() followed by register() and things are backlogged enough that this particular race happens.