Mozilla Add-ons Community Blog
Categories: developers webextensions

Manifest v3 in Firefox: Recap & Next Steps

12 responses

It’s been about a year since our last update regarding Manifest v3. A lot has changed since then, not least of which has been the formation of a community group under the W3C to advance cross-browser WebExtensions (WECG).

In our previous update, we announced that we would be supporting MV3 and mentioned Service Workers as a replacement for background pages. Since then, it became apparent that numerous use cases would be at risk if this were to proceed as is, so we went back to the drawing board. We proposed Event Pages in the WECG, which has been welcomed by the community and supported by Apple in Safari.

Today, we’re kicking off our Developer Preview program to gather feedback on our implementation of MV3. To set the stage, we want to outline the choices we’ve made in adopting MV3 in Firefox, some of the improvements we’re most excited about, and then talk about the ways we’ve chosen to diverge from the model Chrome originally proposed.

Why are we adopting MV3?

When we decided to move to WebExtensions in 2015, it was a long term bet on cross-browser compatibility. We believed then, as we do now, that users would be best served by having useful extensions available for as many browsers as possible. By the end of 2017 we had completed that transition and moved completely to the WebExtensions model. Today, many cross-platform extensions require only minimal changes to work across major browsers. We consider this move to be a long-term success, and we remain committed to the model.

In 2018, Chrome announced Manifest v3, followed by Microsoft adopting Chromium as the base for the new Edge browser. This means that support for MV3, by virtue of the combined share of Chromium-based browsers, will be a de facto standard for browser extensions in the foreseeable future. We believe that working with other browser vendors in the context of the WECG is the best path toward a healthy ecosystem that balances the needs of its users and developers. For Mozilla, this is a long term bet on a standards-driven future for WebExtensions.

Why is MV3 important to improving WebExtensions?

Manifest V3 is the next iteration of WebExtensions, and offers the opportunity to introduce improvements that would otherwise not be possible due to concerns with backward compatibility. MV2 had architectural constraints that made some issues difficult to address; with MV3 we are able to make changes to address this.

One core part of the extension architecture is the background page, which lives forever by design. Due to memory or platform constraints (e.g. on Android), we can’t guarantee this state, and termination of the background page (along with the extension) is sometimes inevitable. In MV3, we’re introducing a new architecture: the background script must be designed to be restartable. To support this, we’ve reworked existing and introduced new APIs, enabling extensions to declare how the browser should behave without requiring the background script.

Another core part of extensions are content scripts, to directly interact with web pages. We are blocking unsafe coding practices and are offering more secure alternatives to improve the base security of extensions: string-based code execution has been removed from extension APIs. Moreover, to improve the isolation of data between different origins, cross-origin requests are no longer possible from content scripts, unless the destination website opts in via CORS.

User controls for site access

Extensions often need to access user data on websites. While that has enabled extensions to provide powerful features and address numerous user needs, we’ve also seen misuse that impacts user’s privacy.

Starting with MV3, we’ll be treating all site access requests from extensions as optional, and provide users with transparency and controls to make it easier to manage which extensions can access their data for each website.

At the same time, we’ll be encouraging extensions to use models that don’t require permanent access to all websites, by making it easier to grant access for extensions with a narrow scope, or just temporarily. We are continuing to evaluate how to best handle cases, such as privacy and security extensions, that need the ability to intercept or affect all websites in order to fully protect our users.

What are we doing differently in Firefox?

WebRequest

One of the most controversial changes of Chrome’s MV3 approach is the removal of blocking WebRequest, which provides a level of power and flexibility that is critical to enabling advanced privacy and content blocking features. Unfortunately, that power has also been used to harm users in a variety of ways. Chrome’s solution in MV3 was to define a more narrowly scoped API (declarativeNetRequest) as a replacement. However, this will limit the capabilities of certain types of privacy extensions without adequate replacement.

Mozilla will maintain support for blocking WebRequest in MV3. To maximize compatibility with other browsers, we will also ship support for declarativeNetRequest. We will continue to work with content blockers and other key consumers of this API to identify current and future alternatives where appropriate. Content blocking is one of the most important use cases for extensions, and we are committed to ensuring that Firefox users have access to the best privacy tools available.

Event Pages

Chrome’s version of MV3 introduced Background Service Worker as a replacement for the (persistent) Background Page. Mozilla is working on extension Service Workers in Firefox for compatibility reasons, but also because we like that they’re an event-driven environment with defined lifetimes, already part of the Web Platform with good cross-browser support.

We’ve found Service Workers can’t fully support various use cases we consider important, especially around DOM-related features and APIs. Additionally, the worker environment is not as familiar to regular web developers, and our developer community has expressed that completely rewriting extensions can be tedious for thousands of independent developers of existing extensions.

In Firefox, we have decided to support Event Pages in MV3, and our developer preview will not include Service Workers (we’re continuing to work on supporting these for a future release). This will help developers to more easily migrate existing persistent background pages to support MV3 while retaining access to all of the DOM related features available in MV2. We will also support Event Pages in MV2 in an upcoming release, which will additionally aid migration by allowing extensions to transition existing MV2 extensions over a series of releases.

Next Steps for Firefox

In launching our Developer Preview program for Manifest v3, our hope is that authors will test out our MV3 implementation to help us identify gaps or incompatibilities in our implementation. Work is continuing in parallel, and we expect to launch MV3 support for all users by the end of 2022. As we get closer to completion, we will follow up with more detail on timing and how we will support extensions through the transition.

For more information on the Manifest v3 Developer Preview, please check out the migration guide.  If you have questions or feedback on Manifest v3, we would love to hear from you on the Firefox Add-ons Discourse.

12 comments on “Manifest v3 in Firefox: Recap & Next Steps”

  1. Stefan wrote on

    Hi Firefox team,

    As a member of the W3 browser extension group.
    It is good to hear that you will support the persistent background page for MV3. So my Turn Off the Lights Firefox extension can continue to deliver the support of my accessibility feature for my Firefox users. https://www.turnoffthelights.com/firefox

    Thanks,

    1. Rob Wu wrote on

      Just to clarify, MV3 will receive support for event pages, not *persistent* background pages. They share mostly the same set of APIs, but extensions built on event pages should be designed to be resilient against inevitable termination. This reflects the reality where the browser does not always have a choice in whether to keep an extension process alive.

  2. Vladimir Prelovac wrote on

    What will become the ground truth for WebExtensions API?

    Currently it is
    https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions

    but it covers v2 only. Will v3 be added and in what way will be differences in v3 implementation across browsers be highlighted?

    1. Rob Wu wrote on

      MDN is still the ground truth of documentation for WebExtension APIs.

      For example, the tabs.executeScript API, whose functionality has moved to the scripting namespace, has a notice that mentions that the it’s MV2 only, with the alternative being linked. Its compatibility table also mentions that the method is MV2-only. See it for yourself at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/executeScript.

  3. zakius wrote on

    There are multiple usecases for persistent background pages: proper mouse gestures and keyboard shortcuts have to be ran there (using additional, currently missing, APIs though) as ContentScripts are too limited and unreliable, due to lack of SQL compatible storage (and boot time of workarounds) you need persistent background page when you use searchable database too (using IndexedDB shenanigans to somehow get it working would be messy and likely unreliable with short lived event pages).
    Besides that many extensions have to make CORS requests, otherwise they wouldn’t work… I’m guessing you’re forcing the CS to execute event that will then perform the request and message the result back? That’s not great. And what about userscripts performing CORS requests? Does the moder Userscripts API allow that, or is that going away completely?

    I know you intend to keep supporting Mv2 in the foreseeable future, but these issues are really scary. And looking at the current state of WebExtensions (so… no issues I pointed out when you announced building Chromium model copy resolved yet…) I’m afraid once Mv2 goes away we’ll lose another big chunk of extensions and you’ll do nothing to prevent it.

    1. Rob Wu wrote on

      > Besides that many extensions have to make CORS requests, otherwise they wouldn’t work… I’m guessing you’re forcing the CS to execute event that will then perform the request and message the result back?

      Content script can still send cross-origin requests if the destination cooperates using the [standard CORS mechanism](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). Other requests would indeed require the assistance of the background script.

      > And what about userscripts performing CORS requests? Does the moder Userscripts API allow that, or is that going away completely?

      Most of the current user script extensions have a suboptimal security architecture, because all user scripts are executed in the same environment as the content script. Because the underlying primitive (string-based code execution in content scripts) have been removed, user script managers can currently not be ported to MV3.

      We are looking for a way to allow user script managers to continue working, ideally in a more secure way. While we already had a userScripts API, its API would have to change to stay reliable in MV3. Since the API had to change anyway, we are re-examining its design, in the hopes of reaching an interoperable API that enables extension developers to build cross-browser user script managers.

      1. zakius wrote on

        while I understand and value the push for privacy and security I believe it’s important to leave users the freedom to decide what potential risks they are willing to take for power and convenience, that’s why WebExtensions, while finally a proper API, were a big step back for Mozilla

        I like how Android does some things: there are permissions that can be required by an app to even be installed and these are granted automatically, there are ones to be called on runtime that user can grant with a simple modal, there are ones that user has to grant using the settings app for increased security, and on top of that there are ones you need ADB or root to grant and these (or at least some of) only persist until device reboot. Such a permissions model would allow much more power while keeping the top security, though obviously it’s a lot of work to do, but then again, currently we are missing a lot of power already, and Mv3 is only going to make things worse in that aspect, so pushing towards improving the situation would be a great improvement

  4. Dmytro wrote on

    Hi! Thanks for update!

    Quick question: In manifest v2 we used web-worker for wasm on the background page but now we can’t create a web-worker inside service worker.

    Maybe someone knows a workaround for this?

    1. rmus18 wrote on

      I have also faced this issue. Service workers don’t have access to the window and web workers are now useless. For now I’ve just ran the web worker script in promise calls but have not found a full solution.

      1. guest271314 wrote on

        It is possible to communicate between arbitrary Web page and MV3 ServiceWorker using “web_accessible_resources”, embedding an that loads a local Web accessible resource, and clients.matchAll({includeUncontrolled: true})) in ServiceWorker. See https://github.com/GoogleChrome/developer.chrome.com/issues/2688#issuecomment-1128295345.

    2. Shane Caraveo wrote on

      If you require the use of a worker or DOM APIs, in Firefox you can just use event pages rather than the service worker background. Our Developer Preview only supports the event pages now, but we intend to support both in the future.

  5. Expect to lose many WebExtensions wrote on

    MV3 is like taking a Ferrari (current MV2 with all the features), removing the engine and then saying “just race!”. All you can do is to take the car on top of the hill and let it roll down. Then tow it back up manually and repeat.

    Taking away persistent background pages is one of the most idiotic architectural changes I have ever heard of. The power of many extensions is based on the fact that they can process lots of data and keep it cached in the background page enabling fast UI and access. If you have to reparse and reprocess this data all the time, performance of the application becomes unacceptable.

    I find it weird that no-one seems to care about that at all.