Manifest v3 update

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.

21 responses

  1. gchristnsn wrote on :

    >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
    >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.

    1. Do not remove the background pages. They are good and allow to trade memory for performance.
    2. Modularize service workers or large codebases will be thrown away. See https://stackoverflow.com/questions/66406672/chrome-extension-mv3-modularize-service-worker-js-file for example.

    1. Alex wrote on :

      “Do not remove the background pages. They are good and allow to trade memory for performance.”

      Agreeing with this comment. My WebExtension caches frequently-accessed variables in the background page to make them available to my extension pages. Being forced to repeatedly save their values in local storage and then access them every time they’re required would be inefficient and expensive, not to mention the potential of having to implement painful and difficult-to-maintain workarounds for limitations imposed by this design. It would be great if Manifest v3 offered a hybrid solution that allows for a combination of service workers and background pages.

  2. Blaise Kal wrote on :

    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?

    1. Luca Greco wrote on :

      They should be mostly unified in Manifest v3, and we’re happy to collaborate with Google to iron out any remaining differences.

  3. BelFox wrote on :

    Great that you keep supporting blocking webRequest! Firefox needs things like these to differentiate itself from other browsers.

    Good decision.

  4. Kevin wrote on :

    A suggestion for a future manifest is to allow extensions to modify the Firefox UI with css. Browser customization is what separates the fox from chrome and I have plenty of ideas on extensions that could make use of this. (Cpu or resource monitor displayed in the tab, compact mode, etc) Please make this happen!

    1. John wrote on :

      I’ll second this as well.

      it’s a nice feature.
      Yes it would allow substantial visual differences from the standard UI and easy product identification thru visuals would suffer, but i believe we will gain more than we’ll loose with this.

    2. Rob Wu wrote on :

      Power users can already fully customize parts of the browser with CSS via userChrome.css; see the tutorial at https://www.reddit.com/r/FirefoxCSS/wiki/index/tutorials from the /r/FirefoxCSS community.

      There is also an experimental extension API called `theme_experiment` to include a stylesheet of the browser in an extension. This feature is only available on Nightly and Firefox Developer Edition with non-default preferences, see https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme_experiment

      1. Thomas wrote on :

        Rob, userChrome.css is great but let’s not pretend that it is a replacement for officially supported theme APIs that are stable, easy to modify, extend, install and use from an extension author and user perspective. This is an area where Firefox is lacking right now but could really improve and stand out from the rest of the browsers.

        1. Dan Veditz wrote on :

          He’s not pretending any such thing! After noting what can be used right now he pointed at an ongoing experiment with a new theming feature for extensions. That might not be what you want either — that’s why we experiment — but we wouldn’t bother trying new things if we thought userChrome.css was the perfect answer.

          Have you tried it?

          1. Thomas wrote on :

            Dan, I didn’t mean Rob was pretending in the literal sense. But my apologies, Rob, if you felt my choice of words were wrong/hurtful, that was definitely not my intention. What I meant was that the experiment theme API and userChrome.css in particular while powerful are not suitable for many users as they are experimental, unstable and/or relegated to power users.

            Progress on WebExtensions APIs has been relatively slow moving so it’s unclear if such experiment API will grow in scope and if it will ever be able to be used in the standard release build. It just seems that apart from recent MV3 related changes new WebExtensions API additions have taken a backseat for the last few years. Please don’t take this as personal criticism, I understand this is primarily due to architectural changes and task reshuffling/resource issues. From an outside view, it’s just hard to find out exactly what API additions and enhancements are planned for Firefox WebExtensions in the future and any possible release ETA.

  5. Tommy wrote on :

    Another big obstacle with Chrome MV3 is the loss of support for loading external libraries like GAPI. How does Mozilla plan to handle this?

    1. Rob Wu wrote on :

      Loading remote code has always been against the policies of Mozilla because of the security risks that are associated with it, see https://extensionworkshop.com/documentation/publish/add-on-policies/#development-practices

      Extensions should bundle code that they are using. Libraries that depend on third-party servers can often be replaced with code that directly communicates with the endpoints. We’ve previously shared a specific example, at https://blog.mozilla.org/addons/2016/05/31/using-google-analytics-in-extensions/

  6. Long live Firefox wrote on :

    Mozilla thank you for keeping webRequest and extending and creating more useful APIs! You guys are our only hope to keep the web in the hands of users and against a Big Tech vision of a tracked and curated corp web.

    Especially you Rob Wu and others on the extensions team. I hope you guys realize how much what you all do impacts the web. Please never falter, internet users of the present and future desperately need the power that you are in a position to provide!

  7. jay2007tech wrote on :

    I recommend messaging the authors of the extensions and ask for there input on any possible encounters that they may see or possible concerns on when migrating Chrome extensions to Manifest v3.

    adding a little extra stuff to the api’s if a suggestion is popular enough. Its about making the developers job a little easier and more room to work with their creative ideas 🙂

  8. jay2007tech wrote on :

    sorry for the double post (maybe a moderator can merge my 2 post together) 🙂

    I just wanted to show an example on some of the limitations that developers face like from here
    hxxps://gitlab.com/smart-referrer/smart-referer/-/issues/138

    these is no real solution to protect document.referrer from leaking. Adding some code to the proper API would make it happen

  9. Anon1195 wrote on :

    >Host permission controls

    So with this I must explicitly allow, let’s say Ublock, to work on each page every time I visit it? Will be there an option like “run it on all urls” so I can choose it and don’t mess with pop-up/warnings every time I visit new page ?

    1. Rob Wu wrote on :

      Some extensions do legitimately need to run everywhere, like the example that you’ve mentioned. In these cases our current plan is to enable users to configure the extension to run everywhere.

  10. asamuzaK wrote on :

    Supporting background service workers for compatibility is good, but removing support for background pages / scripts is a VERY VERY bad decision.
    The inability to access to the DOM and read / write to the clipboard from the background, and the inability to establish a persistent port connection with the Native Messaging Host have led to a number of complaints from Chrome extension developers.
    There’s no need for Mozilla to revisit the obvious path of failure.
    It’s total nonsense.

    Refs
    * Add support for parsing XML and HTML documents to Manifest V3
    https://bugs.chromium.org/p/chromium/issues/detail?id=1056354
    * Cannot read clipboard from service worker in a MV3 chrome extension
    https://bugs.chromium.org/p/chromium/issues/detail?id=1160302
    * Chrome browser running a MV3 extension that uses Native Messaging does not respond to messages from the Native Messaging Host after 5 minutes
    https://bugs.chromium.org/p/chromium/issues/detail?id=1189678

  11. Anu Kuruvilla wrote on :

    Since persistent background pages are replaced with background service workers, how will the nativeconnection work. Currently my extension does chrome.connectNative at background script startup which launches native process. The process is kept running till the browser instance exits. With background service worker, how is thing going to be? WIll it be possible to keep one instance of the native process running till browser exits, or will extension be forced to do a chrome.connectNative and create an instance of the native process each time that the background service worker gets invoked. Can you provide some light to this concern?

  12. Anu Kuruvilla wrote on :

    Currently we inject content to the webpages to show visual representation. Will this be possible with the shift to manifest V3. Would this require user’s permission per domain to achieve such a functionality?