Proposal: Limited Event Pages for MV3 · Issue #134 · w3c/webextensions · GitHub

Comments

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.