Annonce du support officiel de Puppeteer pour Firefox

• À partir de la version 23 de Puppeteer, Firefox est officiellement pris en charge, ce qui permet désormais d’effectuer facilement de l’automatisation et des tests end-to-end sur Chrome et Firefox
  • const browser = await puppeteer.launch({browser: "firefox"});
• Comme pour Chrome, Puppeteer peut télécharger et exécuter la dernière version stable de Firefox
• Le support de Firefox repose sur WebDriver BiDi, un protocole cross-browser actuellement implémenté dans Gecko et Chromium, et non sur un protocole d’automatisation propre à Firefox
  • L’utilisation d’un protocole cross-browser permettra de prendre plus facilement en charge davantage de navigateurs à l’avenir

Contexte technique

• Jusqu’à récemment, les personnes souhaitant faire de l’automatisation de navigateur avaient deux grands choix
  • utiliser l’API W3C WebDriver
  • utiliser des API dédiées à chaque navigateur (Chrome DevTools Protocol, Firefox Remote Debugging Protocol, etc.)
• Les deux options impliquent des compromis importants
  • l’API WebDriver classique repose sur HTTP, avec un modèle consistant à envoyer des commandes au navigateur puis à attendre la réponse
  • cela fonctionne bien pour des scénarios d’automatisation comme charger une page ou vérifier qu’un élément est affiché, mais c’est inadapté aux cas d’usage avancés comme recevoir des événements du navigateur ou exécuter plusieurs commandes simultanément
  • les API propres à chaque navigateur offrent un ensemble de fonctionnalités bien plus avancé que WebDriver, car elles sont généralement conçues pour prendre en charge les cas d’usage complexes des outils de développement intégrés au navigateur
• Les clients d’automatisation de navigateur devaient donc choisir entre utiliser un protocole unique pour prendre en charge plusieurs navigateurs avec un ensemble de fonctionnalités limité, ou proposer un ensemble plus riche mais implémenter séparément les fonctionnalités pour chaque navigateur pris en charge
• Cela augmentait le coût et la complexité de la création d’une automatisation cross-browser de qualité
• La situation était similaire avant l’arrivée du LSP (Language Server Protocol)
• WebDriver BiDi apporte, dans un protocole standardisé, l’ensemble des fonctionnalités d’automatisation auparavant limitées aux protocoles propres à chaque navigateur, afin qu’elles puissent être utilisées par tous les navigateurs et outils d’automatisation

Suppression du support expérimental de CDP (Chrome DevTools Protocol) dans Firefox

• Dans le cadre des premiers travaux visant à améliorer les tests cross-browser, une implémentation partielle de CDP avait été fournie, limitée à quelques commandes et événements nécessaires pour les cas d’usage de test
• Cependant, il est devenu clair que ce n’était pas la direction à suivre pour faire progresser l’automatisation cross-browser, et les efforts dans ce domaine ont été abandonnés
• En conséquence, ce support n’est plus maintenu et n’est pas compatible avec des fonctionnalités modernes de Firefox comme l’isolation des sites
• Il sera donc supprimé d’ici fin 2024

Suite du programme

• Certaines API ne sont toujours pas prises en charge
  • API exclusives à CDP
  • API nécessitant un travail supplémentaire de standardisation
  • API déjà standardisées mais pas encore implémentées
• Les priorités seront définies à partir des retours des utilisateurs

[xguru]

Commentaires Hacker News

• Le fait que l’équipe Puppeteer ait quitté Google pour Microsoft et ait continué à développer Playwright a été un gros coup dur pour Google

  • Google n’avait pas réalisé à quel point les outils d’automatisation de navigateur étaient importants pour sa stratégie d’agents IA
  • Google a dû soit abandonner Puppeteer et dépendre de MS/Playwright, soit trouver une nouvelle voie pour Puppeteer
  • WebDriver BiDi fait évoluer, sous une forme standardisée, les avantages du Chrome DevTools Protocol (CDP)

• Le protocole WebDriver BiDi n’est pas un protocole conçu pour créer des navigateurs, mais il semble pouvoir remplir ce rôle à près de 90 %

  • Gecko a beaucoup progressé depuis Servo, et ses performances sont aujourd’hui plutôt bonnes
  • Il est bien plus facile de créer un navigateur basé sur Chromium qu’un navigateur basé sur Gecko
  • L’API permet de naviguer, d’intercepter des requêtes, de lire la console, d’exécuter du JS, etc.
  • Ce serait bien de pouvoir retirer le chrome du navigateur et créer un navigateur personnalisé

• Playwright prend en charge tous les moteurs de rendu modernes (Chromium, WebKit, Firefox)

• Curiosité au sujet de l’arbre d’accessibilité

  • La raison pour laquelle l’arbre d’accessibilité a été retiré de Playwright est qu’il s’agissait d’un dump des structures de données internes propres à chaque moteur
  • L’arbre d’accessibilité résume tous les éléments sémantiques d’une page, ce qui est excellent pour les tests par snapshot ou les tests BDD
  • Il serait souhaitable que l’arbre d’accessibilité soit standardisé dans les principaux moteurs de navigateur
  • Du point de vue du développement web, ce serait bien qu’il soit aussi accessible depuis d’autres couches comme le CSS et le DOM