[Manifest V3] WebExtensionWorker instead of Service Worker

[Jack-Works]

I don't know if this repo is going to standardize Manifest V3 but I think I can post it here.

Currently, in Manifest V3, the background worker is reusing the Service Worker, which is a very bad reuse. It inherits many restrictions of the Service Worker which does not make sense to the Web Extension background worker. Here is a list of examples:

• Issue 1159286: Cannot use importScripts after init in Web Extension manifest v3 background service worker
• Issue 1136582: Can't register service workers in non-root directory as the background context of extensions V3

I propose to add a new Worker type like ServiceWorker, WebExtensionWorker. Thus we can gain the following benefits:

• Reconsider the difference between ServiceWorker and WebExtension background worker, apply different restrictions on them.
• WebIDL integration, it easy to specify what API should be exposed via [Expose]
• Tell the developers those things are different, not confused by the name ServiceWorker with a set of special behaviors.

[therealglazou]

I kind of agree with this but the biggest problem we face with MV3 is the fact the ServiceWorker can shut down at any time, and will shut down after 5mins even if it's still active at that moment. This is clearly bearable for "light-weight" extensions, but for "heavy-weight" ones performing crypto, sync and things like that, it's a terrible design choice to switch from a persistent background to a volatile Service Worker...

[Jack-Works]

As I said in the top thread, those limitations (like killed in 5 minutes / inactive) are the limitation of ServiceWorker. If we choose the new mental model, that limitation is not a necessary part of WebExtensionWorker.

[therealglazou]

As I said in the top thread, those limitations (like killed in 5 minutes / inactive) are the limitation of ServiceWorker. If we choose the new mental model, that limitation is not a necessary part of WebExtensionWorker.

Absolutely.

[dotproto]

I don't know if this repo is going to standardize Manifest V3 but I think I can post it here.

IMO discussing the background execution environment for browser extensions is well within this group's charter.

That said, I'm compelled to clarify that this group is not trying to "standardize Manifest V3" or otherwise standardize the browser extension platform. Rather, we are attempting to identify and specify a common core of browser extensions capabilities and APIs. The distinction is subtle, but important (primarily for legal reasons?). I'd encourage anyone interested in digging more into this distinction to read through the W3C's community & business group FAQ.

[wingman-jr-addon]

What does this group think are good next steps for "identifying and specifying a common core" here? It's not clear to me that simply deferring to the most conservative API surface is a good strategy when there seems to be significant contention over the limitations relative to the previous API surface. I like @Jack-Works idea of specifying a WebExtensionWorker instead, but I'm still grappling with how to juxtapose that with @dotproto 's reminder above in a way that remains on topic/on charter.

[ghostwords]

Stepping back, what are Service Workers as they exist today? They are a progressive enhancement to websites:

Service workers essentially act as proxy servers that sit between web applications, the browser, and the network (when available). They are intended, among other things, to enable the creation of effective offline experiences, intercept network requests and take appropriate action based on whether the network is available, and update assets residing on the server.

— MDN

Service workers are specialized JavaScript assets that act as proxies between web browsers and web servers. They aim to improve reliability by providing offline access, as well as boost page performance. ... Service workers are an enhancement to existing websites.

— Service Workers Overview on developer.chrome.com

If you were to apply the concept of Service Workers (SWs) to extensions, what is the "website"? As extensions are a progressive enhancement to the browser, the browser is to extensions as what websites are to SWs.

SW lifetimes are independent of website lifetimes; SWs give websites superpowers. The various execution limits imposed by the browser make sense in this context, as does the more limited API surface available to SWs.

When it comes to extensions, the "website" is the browser itself. Here, limiting the lifespan of extension SWs doesn’t make sense (#72 (comment)), and neither does reducing the API surface available to extension background pages in Manifest V2 (#72).

While there are real use cases the SW-based extensions are meant to address (such as getting extensions to gracefully handle termination in a multiprocess environment on mobile (#51 (comment), #25)), SWs as they exist now in Google's Manifest V3 are not the answer. SWs are a standard for websites, not for browser extensions. If applied as a foundation for all extensions, Service Workers are an inherently user-hostile technology (#51).

[Jack-Works]

A new problem: Chrome implementation bans import() in MV3 background script with type: module in manifest.json, which blocks awesome-webextension/webpack-target-webextension#24 to support MV3 background worker+esmodule

[wingman-jr-addon]

Do you think that's something to put into a use case for #72 ?