Allow workers & shared workers to be created within a service worker

[ian97531]

Update (2022/10/10): This issue was originally making the case for workers and shared workers to be creatable by service workers to enable a chrome extension use case. Since extensions are not part of the web platform, I'm updating the motivating use case here to reflect one pointed out by @wanderview that is relevant to the web platform:

Custom (de)compression algorithms that are cpu intensive can use dedicated workers to avoid introducing delays in fetch event processing.

Also, any site that performs sync with the server and must support multiple tabs has a use for shared workers for managing state. Often that state will need to be accessed from the service worker as well.

Original issue description: As Chrome extensions migrate to manifest v3, their background scripts become service workers. Since extensions cannot reliably spawn web workers from content scripts (due to potential CSP restrictions in the host page), it'd be very useful to be able to spawn web workers from the chrome extension's service worker to execute some WASM.

This was already discussed in 2 other (closed) issues here and here. I figured I'd open a new issue as requested by @annevk (here) since there's now a new use case created by the move to manifest v3.

[asutherland]

To the motivating use-case, at least in Firefox, content scripts operate in their own distinct global[1] which could be provided with its own Worker constructor which need not be subject to page CSP rather than having the spec complexity of the content script using the underlying content page's global.

1: Which does have access to the underlying content page's global and may do some prototype chain tricks for convenience / compat.

[paralin]

Related: spawning Worker, SharedWorker, ServiceWorker from within a SharedWorker.

[domenic]

Extensions are not the web platform, and in particular extension service workers are not web platform service workers. If extension service workers want nested workers, each browser can add them; that doesn't impact the web platform workers specified in web standards.

[wanderview]

There are use cases for dedicated and shared workers in web platform service workers.

Custom (de)compression algorithms that are cpu intensive can use dedicated workers to avoid introducing delays in fetch event processing.

Also, any site that performs sync with the server and must support multiple tabs has a use for shared workers for managing state. Often that state will need to be accessed from the service worker as well.

[ian97531]

Extensions are not the web platform, and in particular extension service workers are not web platform service workers. If extension service workers want nested workers, each browser can add them; that doesn't impact the web platform workers specified in web standards.

Hi @domenic. Does that mean that if nested workers were implemented in the web platform and adopted by browser vendors, extension service workers still wouldn't be able to use nested workers? Thanks for the reply!

[domenic]

Maybe! They're separate spaces. Any of the four outcomes in the matrix { extension service workers support nested workers, extension service workers don't support nested workers } x { web platform service workers support nested workers, web platform service workers don't support nested workers } are possible.

In practice, code sharing means there's some influence. E.g., if the web platform community finds @wanderview's use cases compelling, and implement it for the web platform, then maybe some engineers at some browser would do the extra work to expose the feature to extensions. But it would be extra work, not automatic, and would need its own per-browser approvals and discussions.

My main point is, if you believe extension service workers should support nested workers, then advocating for web platform service workers getting nested workers is not a good tactic. Us web platform engineers are not motivated by adding things to extensions, because extensions are not part of the web platform. Instead, you should work with the engineers designing and shipping extension APIs, which is a very different group from the engineers designing and shipping web platform APIs. (And I don't know where those extension engineers hang out.)

[annevk]

https://github.com/w3c/webextensions seems to be somewhat active at least.

[ian97531]

@annevk @domenic Thanks for the explanation. I'll file something over in the w3c/webextensions issues. In the meantime, I'll leave this issue open and update the description to include @wanderview's use cases since they seem valid for the web platform.

[asutherland]

@wanderview's use cases sound reasonable for the web platform. I think the main question is whether the unique lifetime of ServiceWorkers means that we should consider options like:

• Specializing the SharedWorker lifetime semantics to allow the SharedWorker to treat pages controlled by the ServiceWorker as members of the owner set so that the SharedWorker can remain alive even if the ServiceWorker shuts down due to idleness or because the browser wants to migrate it between processes or reload it for some reason or to enable the ServiceWorker to upgrade without shutting down the SharedWorker.
  • Since it's already possible for every page to establish a connection to the relevant SharedWorker to accomplish the lifetime goals here, the argument here would primarily be to support sites establishing a more clear abstraction boundary between the page and the ServiceWorker. This could enable pages to speak a pure REST API to their ServiceWorker and potentially simplify the ServiceWorker upgrade situation by allowing the ServiceWorker to have more control over the lifetime of the SharedWorker.
  • This also would potentially simplify interception related edge-cases for script-loading.
• Only supporting SharedWorkers in order to avoid sites going out of their way to keep the ServiceWorker alive to keep the dedicated workers alive.

As somewhat referenced above, we would also need to determine the rules for interception for dedicated workers and SharedWorkers. Would they use the exact same script loading mechanism as the ServiceWorker itself and need to be offlined in the "install" phase? Would they always be intercepted by the ServiceWorker that creates them so that they work offline but can be upgraded without upgrading the root ServiceWorker script? Would they just be intercepted based on scope but with a hard requirement that they be intercepted by some ServiceWorker so that the fundamental goal of supporting offline operation is still there? It might be appropriate for some of this discussion to happen in w3c/ServiceWorker#1529 instead.