The dreaded day is here. Starting today (November 21), extensions created with the much debated Manifest V3 technology will be accepted on Firefox’s official add-on store (AMO) for signing. Mozilla is surrendering to the overwhelming power – and market share – of Google Chrome, even though the company has decided to implement its own, more permissive version of MV3. As Mozilla explains, Manifest V3 is an umbrella term for a number of foundational changes to the WebExtensions API in Firefox. The new API was created by Google as a more secure alternative to Manifest V2 for Chrome extensions, but developers have expressed concerns about the stricter limitations that could make ad-blocking tools much less useful than they are today. Extensions and add-ons for Firefox need to be digitally signed to appear on the AMO store, and now developers can start migrating their code while users of the Nightly and Developer Editions of Firefox can test them. General availability of MV3 is planned for Firefox 109, a release scheduled for January 17, 2023.
Mozilla is working to provide a smooth transition to MV3 in Firefox, but users and coders should not fret. The open source browser will continue to support MV2 extensions “for the foreseeable future,” taking a gradual approach and gathering feedback as MV3 matures. Firefox implementation of MV3 will stand apart from other iterations of the technology in two critical ways. First, while other browser vendors introduced declarativeNetRequest (DNR) in favor of blocking Web Request in MV3, Firefox MV3 continues to support blocking Web Request and will support a compatible version of DNR in the future. Blocking Web Request is more flexible than DNR, allowing more use cases in content blocking (ie ad-blockers like the popular uBlock Origin add-on) and other privacy and security extensions. Furthermore, Firefox’s MV3 offers Event Pages as the background script in lieu of Service Workers. Event Pages offer benefits like DOM and Web APIs that aren’t available to Service Workers, Mozilla explained, while also generally providing a simpler migration path. Event Pages (ie non-persistent background pages) are more flexible for developers, compared to the Service Workers (scripts that run and then shut down) alternative proposed by Google.
