Mozilla machte Puppeteers Firefox-Unterstützung zum Standard, nicht zu einem CDP-Klon

Webentwickler testen routinemäßig eine App in mehreren Browsern, und die Automatisierung erzwang lange eine Entscheidung. Die klassische W3C-WebDriver-API erreicht jeden Browser, spricht aber HTTP-Anfrage-Antwort: Seite laden, Befehl ausführen, auf die Antwort warten. Sie kann Konsolenprotokolle oder Netzwerkverkehr nicht streamen und führt Befehle nacheinander aus. Die reichhaltige Alternative — Chromes DevTools Protocol (CDP) oder Firefox' altes Remote Debugging Protocol — funktionierte nur im jeweils eigenen Browser, sodass ein Tool-Autor ein Protokoll pro Engine pflegte. Umfragen nannten Cross-Browser-Testing als einen der größten Schmerzpunkte des Webs.

Der Weg des geringsten Widerstands war Chromes. Puppeteer, die dominante Automatisierungsbibliothek, wuchs mit CDP auf, und als sie 2019 experimentelle Firefox-Unterstützung erhielt, tat Mozilla das, was naheliegend schien: Es implementierte und pflegte eine Teilmenge von CDP in Firefox. Das machte Firefox zu einem dauerhaften Nachfolger. CDP existiert, um Chromes DevTools zu dienen, und ändert sich mit Chromes Bedürfnissen; es ist keine öffentliche Spezifikation; und ein Teilklon konnte niemals die vollständige Puppeteer-API garantieren, sodass niemand wusste, welche Funktionen wo funktionierten.

Mozillas Gegenbewegung wandte die Lehre aus dem Language Server Protocol von Code-Editoren an: Wenn jedes Tool jeden Browser unterstützen muss, besteht die Lösung nicht darin, das Protokoll des Platzhirsches zu kopieren, sondern den reichhaltigen Funktionsumfang zum Standard zu machen. Mit dem Puppeteer-Team und anderen Mitgliedern der W3C Browser Testing and Tools Working Group baute es WebDriver BiDi — WebDriver-Befehle über einen bidirektionalen, ereignisbasierten WebSocket-Kanal, sodass Protokolle, Netzwerk-Interception, Preload-Skripte und gleichzeitige Befehle browserübergreifend funktionieren. Gecko implementierte die Spezifikation; Chromium implementierte sie ebenfalls.

Bis August 2024 ging die Wette auf: Firefox 129 und Puppeteer 23 lieferten beide produktionsreifes WebDriver BiDi aus, und puppeteer.launch({ browser: 'firefox' }) gab Firefox dieselbe Entwicklererfahrung wie Chrome. Firefox stellte seine CDP-Teilmenge als veraltet ein, mit Entfernung zum Ende 2024 geplant, und die Ankündigung des Chrome-Teams sagte dasselbe: Ab Version 23 läuft die Firefox-Unterstützung auf dem Standard, während Chrome CDP als Standard beibehält. Der Standard, nicht ein Klon, war Firefox' Einstieg geworden.

Das reichhaltige Protokoll gemeinsam mit dem Rivalen als offenen W3C-Standard verfassen — dann liefert dessen eigenes Puppeteer Firefox für einen aus

Das Protokoll bidirektional und ereignisgesteuert zu machen, gab dem Tooling Funktionen auf CDP-Niveau — Protokolle, Netzwerk-Interception, Nebenläufigkeit — ohne die browserübergreifende Reichweite aufzugeben.

Die gemeinsame Verfassung beim W3C mit Chromium bedeutete, dass kein einzelner Anbieter das Protokoll besaß; Firefox pflegte nicht länger ein privates Protokoll, das für Chromes DevTools geschrieben war.

Weil Puppeteer CDP als Chromes Standard beibehielt, blieben bestehende Automatisierungen unberührt, während seine Firefox-Unterstützung auf dem Standard lief — Googles Bibliothek lieferte Mozillas Kompatibilität kostenlos aus.

Sobald BiDi in Puppeteer Funktionsparität erreichte, konnte Firefox seine CDP-Teilmenge und deren Wartungslast als veraltet einstufen, sodass der Standard als einziger Weg nach vorn blieb.

Wenn ein Rivale das De-facto-Protokoll besitzt, klone es nicht und bekämpfe es nicht — verfasse gemeinsam einen öffentlichen Standard, den beide Engines implementieren, und das dominante Tool wird zu deinem Vertriebskanal.

Firefox 129 stufte CDP bei Erscheinen als veraltet ein, mit Entfernung zum Ende 2024 geplant, und beide Teams baten Nutzer, zu migrieren oder fehlende APIs zu melden. Einige Puppeteer-Funktionen schafften den Sprung nicht — CDPSession-spezifische Aufrufe, Momentaufnahmen des Accessibility-Tree und Worker-Evaluierung brauchen noch Standardisierungsarbeit — und die Teams veröffentlichten die offene Liste. Eine Woche zuvor hatte BrowserStack WebDriver BiDi in seiner Cloud als produktionsreif erklärt, Teil einer Phase, in der das Protokoll von der Spezifikation zu ausgelieferter browserübergreifender Infrastruktur wurde.