https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/ * Skip to main content * Skip to sidebar Mozilla Add-ons Blog Mozilla Manifest v3 update Rob Wu # 2 responses May 27 2021 [addons-octopus-1-160x] Two years ago, Google proposed Manifest v3, a number of foundational changes to the Chrome extension framework. Many of these changes introduce new incompatibilities between Firefox and Chrome. As we previously wrote, we want to maintain a high degree of compatibility to support cross-browser development. We will introduce Manifest v3 support for Firefox extensions. However, we will diverge from Chrome's implementation where we think it matters and our values point to a different solution. For the last few months, we have consulted with extension developers and Firefox's engineering leadership about our approach to Manifest v3. The following is an overview of our plan to move forward, which is based on those conversations. High level changes * In our initial response to the Manifest v3 proposal, we committed to implementing cross-origin protections. Some of this work is underway as part of Site Isolation, a larger reworking of Firefox's architecture to isolate sites from each other. You can test how your extension performs in site isolation on the Nightly pre-release channel by going to about:preferences#experimental and enabling Fission (Site Isolation). This feature will be gradually enabled by default on Firefox Beta in the upcoming months and will start rolling out a small percentage of release users in Q3 2021. Cross-origin requests in content scripts already encounter restrictions by advances of the web platform (e.g. SameSite cookies, CORP) and privacy features of Firefox (e.g. state partitioning). To support extensions, we are allowing extension scripts with sufficient host permissions to be exempted from these policies. Content scripts won't benefit from these improvements, and will eventually have the same kind of permissions as regular web pages (bug 1578405). We will continue to develop APIs to enable extensions to perform cross-origin requests that respect the user's privacy choices (e.g. bug 1670278, bug 1698863). * Background pages will be replaced by background service workers ( bug 1578286). This is a substantial change and will continue to be developed over the next few months. We will make a new announcement once we have something that can be tested in Nightly. * Promise-based APIs: Our APIs have been Promise-based since their inception using the browser.* namespace and we published a polyfill to offer consistent behavior across browsers that only support the chrome.* namespace. For Manifest v3, we will enable Promise-based APIs in the chrome.* namespace as well. * Host permission controls (bug 1711787): Chrome has shipped a feature that gives users control over which sites extensions are allowed to run on. We're working on our own design that puts users in control, including early work by our Outreachy intern Richa Sharma on a project to give users the ability to decide if extensions will run in different container tabs (bug 1683056). Stay tuned for more information about that project! * Code execution: Dynamic code execution in privileged extension contexts will be restricted by default (bug 1687763). A content security policy for content scripts will be introduced (bug 1581608). The existing userScripts and contentScripts APIs will be reworked to support service worker-based extensions (bug 1687761). declarativeNetRequest Google has introduced declarativeNetRequest (DNR) to replace the blocking webRequest API. This impacts the capabilities of extensions that process network requests (including but not limited to content blockers) by limiting the number of rules an extension can use, as well as available filters and actions. After discussing this with several content blocking extension developers, we have decided to implement DNR and continue maintaining support for blocking webRequest. Our initial goal for implementing DNR is to provide compatibility with Chrome so developers do not have to support multiple code bases if they do not want to. With both APIs supported in Firefox, developers can choose the approach that works best for them and their users. We will support blocking webRequest until there's a better solution which covers all use cases we consider important, since DNR as currently implemented by Chrome does not yet meet the needs of extension developers. You can follow our progress on implementing DNR in bug 1687755. Implementation timeline Manifest v3 is a large platform project, and some parts of it will take longer than others to implement. As of this writing, we are hoping to complete enough work on this project to support developer testing in Q4 2021 and start accepting v3 submissions in early 2022. This schedule may be pushed back or delayed due to unforeseeable circumstances. We'd like to note that it's still very early to be talking about migrating extensions to Manifest v3. We have not yet set a deprecation date for Manifest v2 but expect it to be supported for at least one year after Manifest v3 becomes stable in the release channel. Get involved We understand that extension developers will need to adapt their extensions to be compatible with Manifest v3, and we would like to make this process as smooth as possible. Please let us know about any pain points you might have encountered when migrating Chrome extensions to Manifest v3, and any suggested mitigations, on our community forum or in relevant issues on Bugzilla. We are also interested in hearing about specific use cases we should keep in mind so that your extension will be compatible with Chrome for Manifest V3. Categories: developers, general, manifest v3, webextensions 2 responses Post a comment 1. Blaise Kal [af5da510] wrote on May 27, 2021 at 11:17 am: If we want to support both Chrome and Firefox on Manifest v3, do we need to keep using a polyfill like v2? If so, are there any plans to completely unify the interface with Chrome at a later stage? Reply 2. BelFox [ebf2d70e] wrote on May 27, 2021 at 11:48 am: Great that you keep supporting blocking webRequest! Firefox needs things like these to differentiate itself from other browsers. Good decision. 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 [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] 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