1447197 - Trying to `start` a service worker seems broken

Status: RESOLVED FIXED

(DevTools :: about:debugging, defect, P2)

Description

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

STR:

1. Open about:debugging
2. Load the demo page https://serviceworke.rs/strategy-network-or-cache_demo.html
3. The service worker shows as stopped
4. Try to start it

AR:

error occurred while processing 'listWorkers: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIServiceWorkerManager.getRegistrationByPrincipal]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/worker.js :: _getServiceWorkerRegistrationInfo :: line 157"  data: no]
Stack: _getServiceWorkerRegistrationInfo@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/worker.js:157:12
form@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/worker.js:53:26
onListWorkers/</<.workers<@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/root.js:468:40
onListWorkers/<@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/root.js:468:20
Line: 157, column: 0

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(I currently have the e10s multi-opt-out applied / only one content process.)

Comment 2

[Julian Descottes [:jdescottes]]

Interesting, it doesn't seem to happen with every serviceworker. For instance https://serviceworke.rs/offline-status_demo.html works fine.

Not sure if this is related, but the scope for the SW at https://serviceworke.rs/strategy-network-or-cache_demo.html is https://serviceworke.rs/strategy-network-or-cache/controlled which leads to an error page.

Comment 3

[Julian Descottes [:jdescottes]]

Testing quickly, it seems to fail with any service worker registered with a scope different from the default one.

Comment 4

[Julian Descottes [:jdescottes]]

Blocking m1.1 on this one, it is pretty frequent to hit this use case with real service workers so this should definitely be fixed before shipping.

Comment 5

[Julian Descottes [:jdescottes]]

:bhackett looked at the exception in scope of https://phabricator.services.mozilla.com/D47543
It seems to only occur when calling getRegistrationByPrincipal from the content process (only happens when parent_intercept is false), but not all the time. More precisely it seems to happen when the actual worker is being stopped/destroyed/removed...

I looked a bit more into the role of the exception in our current workflow:

This works around the swm.getRegistrationByPrincipal(this._dbg.principal, this._dbg.url) call throwing NS_ERROR_FAILURE when running in a content process.

It's not consistently throwing in that case, otherwise we could simply avoid calling this from the content process.
Normally the API works from the content process.

This change makes aboutdebugging serviceworker tests take a lot longer (some of them are even timing out on my machine).
It's interesting because we see the same kind of timeout issues when the serviceworker parent_intercept refactor is enabled.

We seem to rely on this error to detect that the worker has been destroyed. If you look at root.js, we have a try catch around calls to listWorker.
When the API throws, we get registrations but no worker. This means the service worker is stopped in our logic.
Without the exception, the serviceworker will stay as "registering" (which is wrong) for a while before finally disappearing.

The exception itself might not be crucial to fix since it should be gone when parent_intercept is set to true, but this highlights that we don't properly handle the end of the serviceworker lifecycle, and just rely on the exception happening to transition from running to stopped.

Comment 6

[Belén [:ladybenko]]

This seems not to happen anymore, after the refactor. Closing the bug.