Ankündigung der offiziellen Unterstützung von Puppeteer für Firefox

• Ab Puppeteer Version 23 wird Firefox offiziell unterstützt, sodass sich Automatisierung und End-to-End-Testing nun einfach in Chrome und Firefox durchführen lassen
  • const browser = await puppeteer.launch({browser: "firefox"});
• Genau wie bei Chrome kann Puppeteer die neueste stabile Version von Firefox herunterladen und ausführen
• Die Firefox-Unterstützung basiert nicht auf einem Firefox-spezifischen Automatisierungsprotokoll, sondern auf WebDriver BiDi, einem browserübergreifenden Protokoll, das derzeit in Gecko und Chromium implementiert ist
  • Durch die Nutzung eines browserübergreifenden Protokolls können künftig einfacher weitere Browser unterstützt werden

Technischer Hintergrund

• Bis vor Kurzem gab es für alle, die Browser-Automatisierung wollten, zwei wesentliche Optionen
  • Nutzung der W3C WebDriver API
  • Nutzung browserspezifischer APIs (Chrome DevTools Protocol, Firefox Remote Debugging Protocol usw.)
• Beide Optionen bringen erhebliche Trade-offs mit sich
  • Die klassische WebDriver API ist HTTP-basiert und folgt einem Modell, bei dem Befehle an den Browser gesendet und auf Antworten gewartet wird
  • Das funktioniert gut für Automatisierungsszenarien wie das Laden einer Seite und das Prüfen, ob Elemente angezeigt werden, ist aber für fortgeschrittene Anwendungsfälle wie das Empfangen von Events aus dem Browser oder das gleichzeitige Ausführen mehrerer Befehle ungeeignet
  • Browserspezifische APIs bieten im Allgemeinen einen Funktionsumfang, der WebDriver deutlich voraus ist, da sie üblicherweise dafür entworfen wurden, komplexe Anwendungsfälle der Entwicklerwerkzeuge im Browser zu unterstützen
• Daher mussten Clients für Browser-Automatisierung entweder mehrere Browser mit einem einzigen Protokoll und eingeschränktem Funktionsumfang unterstützen oder einen reichhaltigeren Funktionsumfang anbieten, dafür aber Features für jeden unterstützten Browser separat implementieren
• Das erhöhte die Kosten und die Komplexität für die Erstellung guter browserübergreifender Automatisierung
• Die Situation war ähnlich wie vor der Entwicklung des LSP (Language Server Protocol)
• WebDriver BiDi überführt den Funktionsumfang für Automatisierung, der zuvor auf browserspezifische Protokolle beschränkt war, in ein standardisiertes Protokoll, damit er in allen Browsern und Automatisierungs-Tools genutzt werden kann

Entfernung der experimentellen CDP-Unterstützung (Chrome DevTools Protocol) in Firefox

• Als Teil der frühen Arbeiten zur Verbesserung browserübergreifender Tests wurde eine partielle Implementierung von CDP bereitgestellt, die auf einige Befehle und Events beschränkt war, die für Test-Anwendungsfälle nötig sind
• Da jedoch klar wurde, dass dies nicht die Richtung für die Weiterentwicklung browserübergreifender Automatisierung ist, wurden die Arbeiten daran eingestellt
• Infolgedessen wird sie nicht mehr gepflegt und ist nicht mit modernen Firefox-Funktionen wie Site Isolation kompatibel
• Daher soll die Unterstützung Ende 2024 entfernt werden

Ausblick

• Einige APIs werden weiterhin noch nicht unterstützt
  • CDP-exklusive APIs
  • APIs, die zusätzliche Standardisierungsarbeit erfordern
  • APIs, für die es zwar einen Standard gibt, die aber noch nicht implementiert sind
• Über das Feedback der Nutzer sollen Prioritäten gesetzt werden

[xguru]

Hacker-News-Kommentare

• Dass das Puppeteer-Team Google verlassen und zu Microsoft gewechselt ist, um dort Playwright weiterzuentwickeln, war ein großer Schlag für Google

  • Google hat nicht erkannt, wie wichtig Browser-Automatisierungstools für die Strategie rund um KI-Agenten sind
  • Google musste entweder Puppeteer aufgeben und sich auf MS/Playwright verlassen oder einen neuen Weg für Puppeteer finden
  • WebDriver BiDi entwickelt die Vorteile des Chrome DevTools Protocol (CDP) auf standardisierte Weise weiter

• Das WebDriver-BiDi-Protokoll ist zwar kein Protokoll zum Erstellen von Browsern, aber es scheint fast 90 % dieser Rolle erfüllen zu können

  • Gecko hat sich seit Servo stark weiterentwickelt und liefert inzwischen eine ziemlich gute Performance
  • Einen Chromium-basierten Browser zu bauen ist deutlich einfacher, als einen Gecko-basierten Browser zu bauen
  • Über die API kann man navigieren, Requests abfangen, die Konsole auslesen, JS ausführen usw.
  • Es wäre gut, wenn man die Browser-Chrome entfernen und einen angepassten Browser bauen könnte

• Playwright unterstützt alle modernen Rendering-Engines (Chromium, WebKit, Firefox)

• Frage zur Accessibility-Tree

  • Der Grund, warum der Accessibility-Tree in Playwright entfernt wurde, war, dass er ein Dump der internen Datenstrukturen je Engine war
  • Der Accessibility-Tree fasst alle semantischen Elemente einer Seite zusammen und eignet sich hervorragend für Snapshot-Tests oder BDD-Tests
  • Es wäre wünschenswert, wenn der Accessibility-Tree in den wichtigsten Browser-Engines standardisiert würde
  • Aus Sicht der Webentwicklung wäre es auch gut, wenn darauf in anderen Layern wie CSS und DOM zugegriffen werden könnte