Why Mozilla Maintains Manifest V2 WebRequest in Firefox

This article explores Mozilla’s strategic decision to retain support for the Manifest V2 blocking webRequest API alongside its implementation of Manifest V3 in the Firefox web browser. While Google’s transition to Manifest V3 replaces this powerful API with the more restrictive declarativeNetRequest, Mozilla chose a hybrid approach. By supporting both standards, Firefox preserves the functionality of advanced privacy and content-blocking extensions, upholds user autonomy, and maintains cross-browser compatibility for developers.

The Core Conflict: webRequest vs. declarativeNetRequest

To understand Mozilla's decision, it is necessary to look at how extension architectures work. Google introduced Manifest V3 (MV3) to improve security, privacy, and performance. A major part of Google's update was deprecating the Manifest V2 (MV2) blocking webRequest API and replacing it with declarativeNetRequest (DNR).

  • Blocking webRequest (MV2): Allows extensions to intercept, inspect, and modify network requests in real-time before the browser processes them.
  • declarativeNetRequest (MV3): Forces extensions to hand over a predefined, static list of rules to the browser. The browser then handles the blocking, which severely limits the total number of rules and eliminates dynamic filtering capabilities.

Mozilla disagreed with the idea that the webRequest API needed to be removed to achieve the benefits of MV3.

Preserving Advanced Content Blockers

The primary reason Mozilla retained blocking webRequest is to protect the capabilities of advanced ad blockers and privacy tools, such as uBlock Origin and NoScript.

These extensions rely on dynamic filtering and complex algorithms that DNR cannot replicate. With webRequest, extensions can parse data on the fly, block novel tracking methods, and update their blocklists instantly. Under strict MV3 DNR limits, these extensions are forced to downgrade their features. By keeping webRequest, Firefox ensures that top-tier content blockers remain fully functional.

Prioritizing Privacy and User Agency

Mozilla’s core philosophy revolves around user privacy and an open web. Privacy extensions do much more than just block visual ads; they strip tracking parameters from URLs, block malicious scripts, prevent browser fingerprinting, and modify HTTP headers dynamically.

The restrictive nature of Google's DNR handicaps these specific privacy features. Maintaining webRequest aligns with Mozilla's commitment to giving users complete control over their browsing experience and the data they share with websites.

Addressing Performance and Security Differently

Google cited two main reasons for deprecating blocking webRequest: performance bottlenecks (extensions slowing down page loads) and security risks (malicious extensions reading sensitive user data).

Mozilla acknowledged these concerns but chose to mitigate them without destroying the API:

  • Performance: Firefox implemented MV3’s "Event Pages." This allows background scripts to go to sleep when not in use, capturing the memory and performance benefits of MV3 while leaving webRequest intact for the moments it is actually needed.
  • Security: Instead of restricting what all extensions can do, Mozilla relies on a combination of granular user permissions and a rigorous human and automated review process on its Add-ons store to catch malicious actors.

Ensuring Cross-Browser Compatibility

Mozilla could not ignore Manifest V3 entirely. Because Google Chrome holds the majority of the browser market share, its architecture dictates the standard for extension developers.

By adopting the overarching MV3 framework—including support for DNR—while simultaneously retaining the MV2 blocking webRequest API, Mozilla achieved the best of both worlds. Developers can easily port their Chrome MV3 extensions to Firefox with minimal code changes. Meanwhile, developers who build complex privacy tools can continue utilizing the blocking webRequest API specifically for Firefox users.