The solution
Web developers routinely test one app in several browsers, and automation long forced a choice. The classic W3C WebDriver API reaches every browser, but it speaks HTTP request–response: load a page, run a command, wait for the answer. It cannot stream console logs or network traffic, and it runs commands one at a time. The rich alternative — Chrome's DevTools Protocol (CDP) or Firefox's old Remote Debugging Protocol — worked only in its own browser, so a tool author maintained one protocol per engine. Surveys cited cross-browser testing as one of the web's biggest pain points.
The path of least resistance was Chrome's. Puppeteer, the dominant automation library, grew up on CDP, and when it gained experimental Firefox support in 2019 Mozilla did what seemed natural: it implemented and maintained a subset of CDP inside Firefox. That made Firefox a permanent follower. CDP exists to serve Chrome's DevTools and changes with Chrome's needs; it is not a public specification; and a partial clone could never guarantee the full Puppeteer API, so nobody knew which features worked where.
Mozilla's counter-move applied the Language Server Protocol lesson from code editors: when every tool must support every browser, the fix is not to copy the incumbent's protocol but to make the rich feature set the standard. With the Puppeteer team and other members of the W3C Browser Testing and Tools Working Group it built WebDriver BiDi — WebDriver's commands over a bidirectional, event-based WebSocket channel, so logs, network interception, preload scripts and concurrent commands work across browsers. Gecko implemented the spec; Chromium implemented it too.
By August 2024 the bet cleared: Firefox 129 and Puppeteer 23 both shipped production-ready WebDriver BiDi, and puppeteer.launch({ browser: 'firefox' }) gave Firefox the same developer experience as Chrome. Firefox deprecated its CDP subset, with removal scheduled for the end of 2024, and the Chrome team's own announcement said the same: from version 23, Firefox support runs on the standard while Chrome keeps CDP as its default. The standard, not a clone, had become Firefox's way in.
What it achieved
Co-author the rich protocol as an open W3C standard with the rival — then its own Puppeteer ships Firefox for you
Why it worked
Making the protocol bidirectional and event-driven gave tooling the CDP-class features — logs, network interception, concurrency — without surrendering cross-browser reach.
Co-authoring at the W3C with Chromium meant no single vendor owned the protocol; Firefox was no longer maintaining a private protocol written for Chrome's DevTools.
Because Puppeteer kept CDP as Chrome's default, existing automations stayed untouched while its Firefox support ran on the standard — Google's library shipped Mozilla's compatibility for free.
Once BiDi reached feature parity in Puppeteer, Firefox could deprecate its CDP subset and its maintenance burden, leaving the standard as the only forward path.
What can be applied
When a rival owns the de facto protocol, do not clone it and do not fight it — co-author one public standard both engines implement, and the dominant tool becomes your distribution channel.
Aftermath
Firefox 129 deprecated CDP on arrival, with removal scheduled for the end of 2024, and both teams asked users to migrate or report missing APIs. Some Puppeteer capabilities did not make the jump — CDPSession-specific calls, accessibility-tree snapshots and worker evaluation still need standards work — and the teams published the open list. A week earlier BrowserStack had declared WebDriver BiDi production-ready in its cloud, part of a season in which the protocol moved from spec to shipped cross-browser infrastructure.
FOLLOW THE EVIDENCE
The sources
- Announcing Official Puppeteer Support for Firefox hacks.mozilla.org
- WebDriver BiDi production-ready in Firefox, Chrome and Puppeteer developer.chrome.com
- Puppeteer Support for Firefox (Hacker News discussion) news.ycombinator.com