Proposal: Limited Event Pages for MV3

[zombie]

As part of our work on MV3, Mozilla is working on service workers for extensions in Firefox, both for broad compatibility reasons, and because they’re an event-driven environment with defined lifetimes, and already part of the Web Platform with good cross-browser support.

Chrome’s current implementation of MV3 introduces Background Service Worker as a replacement for the (persistent) background page. However, we’ve found that this approach can’t fully support various use cases we consider important, especially around DOM-related features and APIs.

Additionally, the worker environment is unfamiliar to regular web developers, and we’ve heard repeated complaints from our community that completely rewriting extensions would be an unreasonable burden for the thousands of solo developers and small shops whose existing extensions currently work just fine.

Overall we like many aspects of MV3, and would prefer a speedy transition, so we don’t want our answer to that capability gap to be extending MV2 support indefinitely. Instead, we’re proposing:

Limited Event Pages

These would be similar to existing non-persistent or “event” pages from MV2, with a few additional limitations to align with MV3. They’re a familiar concept for developers and broadly compatible across browsers. They would help with both of our main goals: enabling extensions which can be suspended and resumed as needed, and providing functionality related to the DOM.

One limitation would be that inactive Ports would no longer prevent the Event page from suspending, something Safari for iOS is already doing. Since we’re still in the design phase, we might discover additional limitations as we progress with prototyping.

Otherwise, the same policies and lifetime rules that hold for service workers should be applied to event pages. It seems that there’s a hard 5 minute cutoff in Chromium, but there are no such platform limitations in Gecko, so we’re unlikely to be applying arbitrary time limits, at least on desktop.

MV3 and the future

This is a good opportunity for compromise, with a promising cost-benefit ratio for the short and medium term.

It would afford us time to seek solutions for the missing functionality through the WECG (as part of “MV4”), in the best way possible: either pursuing them through the Web Platform, or by designing extension-specific APIs that work for both browser vendors and extension developers.

And as a result, by the time we’re ready for MV4, the whole ecosystem will probably be in a better position to transition fully to service workers.

[jonathanmayer]

Another advantage of this thoughtful proposal is a possible path forward for a recurring WebExtensions feature request: headless browsing. The same (or very similar) APIs, manifest keys, and implementation could work for privileged event pages and unprivileged content pages.

Edit (prompted by the following comment): I read this proposal as independent of extension lifetime—it exclusively addresses the problems of API availability and extension migration. I strongly agree that there should be an option for persistent extensions.

[ghostwords]

Thanks for the update!

I like that this restores the standard website API surface and I like that this presents a solution for extensions having to get suspended and resumed on mobile.

However, I strongly disagree with applying the same Service Worker-like lifetime limitations to all extensions. Some extensions fit the ephemeral model, many do not.

While Service Workers are indeed defined/standardized/part of the Web Platform for websites, as I argue in #11 (comment) and #72 (comment), there is no Service Worker standard for WebExtensions. The WebExtensions standard is what we make it to be. It should be something that empowers not weakens extensions.

[xeenon]

Thanks for writing this up. I support this proposal for Safari.

[aeharding]

How would this work with websockets? Would an open connection be closed at the 5 minute mark and then need to be reestablished?

[rektide]

The idea that service workers are enough is an unbelievably small minded & pathetic offering. Insultingly way too little. This LEP proposal at least tries to sound reasonable, tries to keep extensions modestly empowered. There's so many web platform APIs that the page has that service workers don't. That we can ask questions like "how would websockets work" shows that this proposal is possibly acceptable, that it is a starting place for what could be found acceptable, versus simply rescinding & taking away almost all the powers extensions have (by making them be service workers).

MV3 can't just drop 90% of the web platform capabilities MV2 offered. That's just not ok, not right. The web & user agency doesn't deserve to be hurt like that & such aggression should be actively strenously heavily resisted. This is a huge huge huge issue.

Thank you so much for opening this proposal. The current ideas in MV3 are batshit insane. Whatever difficulty there is figuring out LEP, it's not the bag full of coal MV3 is currently dropping on us.

[ExE-Boss]

I personally prefer the WebExtensionWorker proposal¹, which avoids the overhead of creating a blank page for every extension with background scripts/modules, but could still have all the DOM APIs exposed for extensions that need them.

Footnotes

1. https://github.com/w3c/webextensions/issues/11 ↩

[xeenon]

Safari Technology Preview 136 and later supports this proposal.

[Sxderp]

I do hope that Mozilla doesn't implement a lifetime, at least on desktop. While this proposal provides support for DOM based APIs it's still lacking in potential performance benefits. Many extensions cache expensive operations for reference later. If those caches are regularly cleared by the browser due to arbitrary lifetimes then overall extension performance goes down.

Honestly, I don't understand how starting and stopping the execution environment really helps with performance. I think to when I'm profiling Python. My code would run for like 10 microseconds but startup of Python environment would take 200. Is that overhead significantly reduced for Browser JS engines?

[Rob--W]

Updated labels to reflect that Firefox has implemented this (many months ago).

Firefox 109 shipped with support for Manifest V3, including support for event pages. Service workers are not supported yet.

Firefox 121 (and Chrome 121) enable extension authors to specify service_worker and scripts under the background key; Firefox will load from scripts, while Chrome will load from service_worker (#282).

[dotproto]

Chrome is opposed to this capability. Firefox and Safari have already implemented it.