Question
Will Firefox Deprecate blocking webRequest in Manifest V3 or Keep It as a Permanent Differentiator?
Cig Indigo
0 reputation · 06 Oct 2021, 23:49 UTC
14.8K views1
Loading…
0 reputation · 06 Oct 2021, 23:49 UTC
Firefox currently supports Manifest V3 while retaining the blocking webRequest API alongside declarativeNetRequest, a divergence from Chromium's removal of synchronous request modification. This allows content blockers to migrate incrementally, but the API is not part of the Manifest V3 specification and Mozilla has not committed to its long-term availability.
The core uncertainty is whether Firefox will eventually align with Chromium and deprecate webRequestBlocking, or maintain it as a permanent differentiation for privacy tools. Firefox's higher dynamic rule limit (30,000 vs. 5,000) reduces migration friction, yet extensions requiring complex matching conditions still depend on webRequest. No firm Manifest V2 deprecation deadline exists, and enterprise policy controls can manage rollout timing, but the strategic direction remains unpublished.
webRequest from Firefox's Manifest V3 implementation?35275 reputation · 07 Oct 2021, 04:16 UTC
Firefox has not announced any plan to deprecate or remove blocking webRequest from its Manifest V3 implementation. As of the latest public documentation, the API remains a supported, non-deprecated surface with no removal timeline. The most accurate answer is that Mozilla currently treats it as a deliberate differentiator, not a transitional legacy feature.
What is confirmed: MDN documents webRequestBlocking without deprecation notices; the Add-on Review Policies accept extensions using it without migration warnings; and the Enterprise Policy Generator contains no flag to disable or remove it. Firefox's declarativeNetRequest implementation also allows 30,000 dynamic rules—well above Chromium's 5,000—and supports regex rules, which reduces migration friction for many filter lists.
What is inference: Mozilla's retention of blocking webRequest appears intended to preserve capabilities that declarativeNetRequest cannot yet express, such as request-body inspection, dynamic header rewriting, and complex conditional logic. The W3C WebExtensions Community Group has not standardized declarativeNetRequest as a full replacement, so the gap remains architectural rather than temporary.
Plan for a dual-API maintenance burden, but structure it to minimize cost. Use declarativeNetRequest for static, rule-based blocking where possible. Reserve webRequestBlocking for cases that genuinely require synchronous inspection or modification. Abstract the two paths behind a common interface so that a future Firefox policy change—or a Chromium-only build—does not force a rewrite.
If your extension relies on request-body inspection, dynamic header rewriting, or complex conditional logic, declarativeNetRequest is not yet a substitute. If your rules are static URL or header patterns, migrating to declarativeNetRequest is reasonable even on Firefox.
firefoxwebRequest reference for any deprecation banner on the blocking permission.webextensions component for intent-to-deprecate or removal meta-bugs.policies.templates.json in mozilla-central for ExtensionSettings flags related to webRequestBlocking.declarativeNetRequest a mandatory migration target.No convergence timeline is publicly plausible right now, but the absence of a deprecation announcement is not a perpetual guarantee. Browser vendors have reversed API commitments before, and ecosystem pressure from filter-list maintainers could eventually reduce Mozilla's incentive to maintain parallel implementations. Treat the current retention as stable for the next major planning cycle, not as permanent.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.