Bugzilla

What the problem is:

Service Workers may be terminated when they're idle, i.e. they've handled an event and there are no more subsequent events dispatched. For debugging purposes, this isn't a desirable behavior. To keep a Service Worker alive when the toolbox opens, the current code on trunk calls `nsIServiceWorkerInfo.attachDebugger` [1]; `nsIServiceWorkerInfo.detachDebugger` is then called when the toolbox closes [2].

This works fine when the `nsIServiceWorkerInfo` and the worker (and thus its corresponding `WorkerTargetActor`) exist in the same process; this is the case for on-trunk code, regardless of the `dom.serviceWorkers.parent_intercept` pref's value (if the pref is on, they'll all exist in the parent process, and if it's off, they'll all exist in a content process).

With all that said, the actual problem is that once the "new implementation" (waiting in bug 1231213) lands, `dom.serviceWorkers.parent_intercept=true` will be so that the `nsIServiceWorkerInfo` and its corresponding worker exist in separate processes. Service Workers will all exist in content processes but be "controlled" from the parent, which means the `nsIServiceWorkerInfo` will exist in the parent, while the `WorkerTargetActor` will exist in a content process. So, we'd like a way to make a cross-process call to `nsIServiceWorkerInfo.{attach,detach}debugger` when the toolbox opens/closes.

The fix

The WIP patch shows what a fix might look like, but it doesn't work due to the `setupInParent` not being available to anything other than Frame and WebExtensions actors (I think). This idea is just to replace the in-process calls in [1] and [2] with cross-process/message manager/IPC calls. A worker and its corresponding `nsIServiceWorkerInfo` will have the same ID (depending on bug 1552945's patches), so the `nsIServiceWorkerInfo` could be obtained by enumerating all `nsIServiceWorkerRegistrationInfo`s in the parent and matching agains their active workers' ID.

Another idea (discussed at All Hands) is to pass the ID of a worker's registration in the toolbox URL. The `attachDebugger` method can be called via `nsIServiceWorkerRegistrationInfo.activeWorker.attachDebugger`, and the worker's ID can be obtained via `nsIServiceWorkerRegistrationInfo.activeWorker.id`, which can be used (I think) to get the WorkerTargeActor.

[1] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/devtools/server/actors/targets/worker.js#68
[2] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/devtools/server/actors/targets/worker.js#178

What the problem is:

Service Workers may be terminated when they're idle, i.e. they've handled an event and there are no more subsequent events dispatched. For debugging purposes, this isn't a desirable behavior. To keep a Service Worker alive when the toolbox opens, the current code on trunk calls `nsIServiceWorkerInfo.attachDebugger` [1]; `nsIServiceWorkerInfo.detachDebugger` is then called when the toolbox closes [2].

This works fine when the `nsIServiceWorkerInfo` and the worker (and thus its corresponding `WorkerTargetActor`) exist in the same process; this is the case for on-trunk code, regardless of the `dom.serviceWorkers.parent_intercept` pref's value (if the pref is on, they'll all exist in the parent process, and if it's off, they'll all exist in a content process).

With all that said, the actual problem is that once the "new implementation" (waiting in bug 1231213) lands, `dom.serviceWorkers.parent_intercept=true` will be so that the `nsIServiceWorkerInfo` and its corresponding worker exist in separate processes. Service Workers will all exist in content processes but be "controlled" from the parent, which means the `nsIServiceWorkerInfo` will exist in the parent, while the `WorkerTargetActor` will exist in a content process. So, we'd like a way to make a cross-process call to `nsIServiceWorkerInfo.{attach,detach}debugger` when the toolbox opens/closes.

The fix

The WIP patch shows what a fix might look like, but it doesn't work due to the `setupInParent` not being available to anything other than Frame and WebExtensions actors (I think). This idea is just to replace the in-process calls in [1] and [2] with cross-process/message manager/IPC calls. A worker and its corresponding `nsIServiceWorkerInfo` will have the same ID (depending on bug 1552945's patches), so the `nsIServiceWorkerInfo` could be obtained by enumerating all `nsIServiceWorkerRegistrationInfo`s in the parent and matching agains their active workers' ID.

Another idea (discussed at All Hands) is to pass an identifier of a worker's registration in the toolbox URL. The `attachDebugger` method can be called via `nsIServiceWorkerRegistrationInfo.activeWorker.attachDebugger`, and the worker's ID can be obtained via `nsIServiceWorkerRegistrationInfo.activeWorker.id`, which can be used (I think) to get the WorkerTargeActor.

[1] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/devtools/server/actors/targets/worker.js#68
[2] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/devtools/server/actors/targets/worker.js#178