Mozilla 讓 Puppeteer 的 Firefox 支援成為標準，而非 CDP 的複製品

Web 開發者經常要在多個瀏覽器中測試同一個應用程式，而自動化長久以來迫使他們做出取捨。經典的 W3C WebDriver API 能觸及所有瀏覽器，但它採用 HTTP 請求–回應模式：載入頁面、執行指令、等待回應。它無法串流主控台日誌或網路流量，而且一次只能執行一個指令。功能豐富的替代方案——Chrome 的 DevTools Protocol（CDP）或 Firefox 舊有的 Remote Debugging Protocol——只能在其各自的瀏覽器中運作，因此工具作者必須為每個引擎維護一套協定。多項調查將跨瀏覽器測試列為 Web 最大的痛點之一。

阻力最小的路徑是追隨 Chrome。Puppeteer 這個主流的自動化函式庫是在 CDP 上成長茁壯的，而當它在 2019 年獲得實驗性的 Firefox 支援時，Mozilla 做了看似自然的選擇：在 Firefox 內實作並維護 CDP 的一個子集。這使 Firefox 成為永久的追隨者。CDP 的存在是為了服務 Chrome 的 DevTools，並隨 Chrome 的需求而變動；它不是公開規格；而部分複製的實作永遠無法保證完整的 Puppeteer API，因此沒有人知道哪些功能在哪裡可用。

Mozilla 的反制之道，套用了程式碼編輯器領域的 Language Server Protocol 教訓：當每個工具都必須支援每個瀏覽器時，解法不是複製現任者的協定，而是讓豐富的功能集成為標準。它與 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 仍以 CDP 作為 Chrome 的預設，既有的自動化腳本原封不動，而其 Firefox 支援則以標準為基礎運作——Google 的函式庫免費提供了 Mozilla 的相容性。

一旦 BiDi 在 Puppeteer 中達到功能對等，Firefox 便能棄用其 CDP 子集及其維護負擔，讓標準成為唯一的前進之路。

當競爭對手掌握了實質上的業界協定，不要複製它，也不要與它對抗——共同起草一套兩個引擎都實作的公開標準，主流工具就會成為你的發行管道。

Firefox 129 一推出便棄用了 CDP，並排定於 2024 年底移除，兩個團隊都請使用者遷移或回報缺少的 API。部分 Puppeteer 功能並未隨之轉移——CDPSession 專屬呼叫、無障礙樹快照與 worker 求值仍需標準層面的工作——團隊也公布了這份公開清單。一週前，BrowserStack 已宣布 WebDriver BiDi 在其雲端環境中可供正式使用，這是該協定從規格邁向實際出貨的跨瀏覽器基礎設施的其中一環。