Firefox Is the Last Major Browser That Still Runs Full uBlock Origin. If You Build a Browser Extension, That's Your Market Now.
Microsoft Edge started a staged shutdown of Manifest V2 extensions in August 2026, cutting off the extension APIs that uBlock Origin's full filtering engine depends on, with Microsoft aiming to finish the consumer rollout by the end of the year. Chrome has been there for over a year: no Manifest V2 extension has run on Chrome stable since Chrome 138 in July 2025, and Chrome 151 stripped the last developer-mode override to restore them on July 28, 2026. That leaves Firefox as the only major traditional browser still running the complete, unrestricted version of uBlock Origin, with Brave, a Chromium-based browser that chose to keep Manifest V2 support anyway, as the one other holdout. If you build, sell, or maintain a browser extension, your market just split along a line that has real technical teeth, not just branding.
I don't build ad blockers, but I've shipped a couple of small Chrome extensions for scraping and workflow automation, and this is exactly the kind of platform shift that quietly kills a side project's roadmap if you're not paying attention to it. Manifest V3 isn't a UI change. It removes capabilities.
What Manifest V3 actually took away
The core loss is the webRequest API, which let an extension intercept and modify network requests before they resolved, the mechanism uBlock Origin's full engine used to block trackers and ads before they ever loaded. Manifest V3 replaces it with declarativeNetRequest, a rules-based system where you register filtering rules in advance rather than intercepting requests dynamically. Chrome raised the rule ceiling under this system to 330,000 rules, up from an earlier 30,000 cap, but a static rule ceiling is a fundamentally different tool than dynamic, request-time filtering, regardless of how high the number goes.
The practical result is uBlock Origin Lite, the MV3-compatible build that Chrome and now Edge users get. It supports a fraction of the filter lists the full version handles, drops most cosmetic filtering (the CSS-based tricks that hide ad containers sites try to keep visible even after the network request is blocked), and loses the real-time network logger that made the full version effective against sites actively trying to detect and defeat ad blockers. It's not nothing. It's meaningfully weaker.
Why Firefox and Brave didn't follow
Firefox has stated it will keep supporting the manifest APIs uBlock Origin needs, meaning Firefox users keep the full extension, webRequest and all. Brave, despite being built on Chromium, the same rendering engine as Chrome and Edge, made an independent choice to preserve Manifest V2 support rather than following Google's deprecation timeline. That's notable because Brave usually inherits Chromium's platform decisions by default, it took a deliberate engineering choice to diverge here.
Both browsers are betting that ad-blocking capability is enough of a differentiator to justify staying off the Manifest V3 path Google set for the entire Chromium ecosystem. For a company like Brave that markets itself partly on privacy and ad-blocking as a core feature, that's a coherent bet. For Firefox, it's consistent with Mozilla's general positioning as the browser that doesn't answer to an ad-revenue-dependent parent company.
The distribution decision this creates
If you build an extension whose value depends on capabilities Manifest V3 restricts, an ad blocker, a price tracker that needs to intercept and modify requests, a scraper that needs broad network visibility, a privacy tool blocking trackers before they fire, you now have three real options instead of one default. Ship to Chrome and Edge under Manifest V3 constraints and accept a weaker product on the browsers with the largest combined market share. Ship to Firefox and Brave where your full feature set works, accepting a smaller but more capable-tool-friendly user base. Or maintain two codebases, a constrained MV3 build and a full-capability MV2-style build, which is real ongoing engineering cost for a solo operator.
None of these are obviously wrong, but "just support Chrome, it's the biggest browser" stopped being a neutral default the moment Chrome's platform constraints became a product limitation rather than a market-share tradeoff. A solo developer weighing whether to build a new ad-blocking or privacy extension today needs to decide up front which side of this split they're building for, because retrofitting a Manifest V2-style product onto Manifest V3's constraints after the fact is a rewrite, not a patch.
What I'd actually do
If I were building a new extension today that leans on real-time network interception, I'd target Firefox and Brave first, where the full capability set is available, and treat a constrained Chrome/Edge build as a secondary release rather than the primary product, accepting that I'm giving up reach for capability. If the extension's value doesn't depend heavily on webRequest-level access, Manifest V3's constraints are mostly irrelevant and this whole split is background noise, not a decision point.
Where this take is shakier: browser market share still overwhelmingly favors Chrome, and a lot of users who'd benefit from the full uBlock Origin experience will never switch browsers just to get it, meaning "build for the smaller, more capable audience" is a real tradeoff, not a free lunch. If your extension's business model depends on total addressable users rather than power-user capability, the Chrome-first calculus might still hold even with the weaker feature set. Know which one you're optimizing for before you commit engineering time either way.
Author
Lukas
@lukcombinator