Mozilla 让 Puppeteer 的 Firefox 支持成为标准，而非 CDP 的克隆

Web 开发者通常会在多种浏览器中测试同一个应用，而自动化长期以来都面临抉择。经典的 W3C WebDriver API 覆盖所有浏览器，但它采用 HTTP 请求-响应模式：加载页面、运行命令、等待结果。它无法流式传输控制台日志或网络流量，而且命令只能逐个执行。丰富的替代方案——Chrome 的 DevTools 协议（CDP）或 Firefox 旧的远程调试协议——只适用于各自的浏览器，因此工具作者需要为每个引擎维护一套协议。调查显示，跨浏览器测试是 Web 开发最大的痛点之一。

阻力最小的路径是沿着 Chrome 走。占主导地位的自动化库 Puppeteer 是在 CDP 上成长起来的，当它在 2019 年获得实验性 Firefox 支持时，Mozilla 的做法似乎很自然：在 Firefox 内部实现并维护 CDP 的一个子集。这使 Firefox 永远处于跟随地位。CDP 的存在是为了服务 Chrome 的 DevTools，并随着 Chrome 的需求而改变；它不是公开的规范；而部分克隆永远无法保证完整的 Puppeteer API，因此没人知道哪些功能在什么位置可用。

Mozilla 的反击运用了代码编辑器领域语言服务器协议的经验：当每个工具都必须支持每个浏览器时，解决方案不是复制现有协议，而是让丰富的功能集成为标准。他们与 Puppeteer 团队以及 W3C 浏览器测试与工具工作组的其他成员共同构建了 WebDriver BiDi——WebDriver 的命令通过双向的、基于事件的 WebSocket 通道传输，因此日志、网络拦截、预加载脚本和并发命令都可以跨浏览器工作。Gecko 实现了该规范；Chromium 也实现了。

到 2024 年 8 月，这个赌注得到了回报：Firefox 129 和 Puppeteer 23 都发布了生产就绪的 WebDriver BiDi，而 puppeteer.launch({ browser: 'firefox' }) 给了 Firefox 与 Chrome 相同的开发者体验。Firefox 弃用了它的 CDP 子集，并计划在 2024 年底移除；Chrome 团队也在公告中表示：从版本 23 开始，Firefox 支持基于标准运行，而 Chrome 继续将 CDP 作为默认。标准，而非克隆，成了 Firefox 的入场券。

与竞争对手共同将丰富的协议制定为开放的 W3C 标准——然后它自家的 Puppeteer 就替你支持 Firefox 了

将协议设计为双向且事件驱动，使工具获得了 CDP 级别的功能——日志、网络拦截、并发——同时保住了跨浏览器的优势。

在 W3C 与 Chromium 团队共同制定标准意味着没有单一厂商拥有协议；Firefox 不再需要维护为 Chrome DevTools 编写的私有协议。

因为 Puppeteer 在 Chrome 上继续将 CDP 作为默认，现有自动化无需改动，而 Firefox 支持则基于标准运行——谷歌的库免费为 Mozilla 提供了兼容性。

一旦 BiDi 在 Puppeteer 中达到功能对等，Firefox 就可以弃用其 CDP 子集并卸下维护负担，让标准成为唯一的前行之路。

当竞争对手掌握了事实标准时，不要克隆它，也不要与之对抗——要共同制定一个双方都实现的标准，这样主导工具就成了你的分发渠道。

Firefox 129 一开始就弃用了 CDP，并计划在 2024 年底移除；两个团队都请用户迁移或报告缺失的 API。一些 Puppeteer 功能未能迁移——CDPSession 专用调用、无障碍树快照和 worker 评估仍需要标准工作——团队公布了公开清单。一周前，BrowserStack 宣布 WebDriver BiDi 在其云上生产就绪，这是该协议从规范走向跨浏览器基础设施的季节的一部分。