https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/ * Skip to main content * Skip to sidebar Mozilla Add-ons Community Blog Mozilla Manifest v3 in Firefox: Recap & Next Steps Rob Wu # 6 responses May 18 2022 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. Categories: developers, general, manifest v3, webextensions 6 responses Post a comment 1. Stefan [6bbc65cd] wrote on May 18, 2022 at 12:14 pm: 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, Reply 1. Rob Wu [30e26944] wrote on May 18, 2022 at 12:49 pm: 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. Reply 2. Vladimir Prelovac [6c6e856c] wrote on May 18, 2022 at 1:47 pm: 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? Reply 1. Rob Wu [30e26944] wrote on May 18, 2022 at 2:49 pm: 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. Reply 3. zakius [9e0918b6] wrote on May 18, 2022 at 2:22 pm: 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. Reply 1. Rob Wu [30e26944] wrote on May 18, 2022 at 3:19 pm: > 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. Reply Post Your Comment Cancel Reply 1. Name (required) [ ] 2. E-mail (required, will not be published) [ ] 3. Spam robots, please fill in this field. Humans should leave it blank. [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] 4. Your comment [ ] 5. Submit Comment [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] About Rob Wu [30e26944] Firefox engineer on the add-ons team at Mozilla. More from Rob Looking for Add-ons? Visit the gallery Categories * builder * compatibility * contests * contribute * developers * documentation * end users * events * featured addons * featured contributors * general * jetpack * manifest v3 * mobile * policy * releases * restartless * sdk * themes * webextensions Return to top Mozilla Except where otherwise noted, content on this site is licensed under the Creative Commons Attribution Share-Alike License v3.0 or any later version. * Contact Us * Privacy Policy * Legal Notices * Report Trademark Abuse * Theme Code