Mozilla a fait du support de Firefox par Puppeteer une norme, pas un clone de CDP

Les développeurs web testent couramment une même application dans plusieurs navigateurs, et l'automatisation a longtemps imposé un choix. L'API classique W3C WebDriver atteint tous les navigateurs, mais elle parle en requête-réponse HTTP : charger une page, exécuter une commande, attendre la réponse. Elle ne peut pas diffuser en continu les journaux de console ni le trafic réseau, et elle exécute les commandes une à la fois. L'alternative riche — le DevTools Protocol (CDP) de Chrome ou l'ancien Remote Debugging Protocol de Firefox — ne fonctionnait que dans son propre navigateur, si bien qu'un auteur d'outil maintenait un protocole par moteur. Les enquêtes citaient les tests multi-navigateurs parmi les plus grands points de douleur du web.

La voie de moindre résistance était celle de Chrome. Puppeteer, la bibliothèque d'automatisation dominante, a grandi avec CDP, et lorsqu'elle a gagné un support expérimental de Firefox en 2019, Mozilla a fait ce qui semblait naturel : implémenter et maintenir un sous-ensemble de CDP dans Firefox. Cela faisait de Firefox un suiveur permanent. CDP existe pour servir les DevTools de Chrome et évolue avec les besoins de Chrome ; ce n'est pas une spécification publique ; et un clone partiel ne pouvait jamais garantir l'API complète de Puppeteer, si bien que personne ne savait quelles fonctionnalités marchaient où.

La contre-offensive de Mozilla a appliqué la leçon du Language Server Protocol venue des éditeurs de code : quand chaque outil doit prendre en charge chaque navigateur, la solution n'est pas de copier le protocole du tenant du titre mais de faire du riche ensemble de fonctionnalités la norme. Avec l'équipe Puppeteer et d'autres membres du groupe de travail Browser Testing and Tools du W3C, elle a construit WebDriver BiDi — les commandes de WebDriver sur un canal WebSocket bidirectionnel et fondé sur les événements, afin que les journaux, l'interception réseau, les scripts de préchargement et les commandes concurrentes fonctionnent sur tous les navigateurs. Gecko a implémenté la spécification ; Chromium l'a implémentée aussi.

En août 2024, le pari était gagné : Firefox 129 et Puppeteer 23 ont tous deux livré WebDriver BiDi prêt pour la production, et puppeteer.launch({ browser: 'firefox' }) offrait à Firefox la même expérience de développement qu'à Chrome. Firefox a déprécié son sous-ensemble CDP, avec un retrait prévu pour la fin 2024, et l'annonce de l'équipe Chrome disait la même chose : à partir de la version 23, le support de Firefox repose sur la norme tandis que Chrome conserve CDP comme défaut. La norme, et non un clone, était devenue la voie d'accès de Firefox.

Coécrire le riche protocole comme norme ouverte du W3C avec le rival — puis son propre Puppeteer livre Firefox pour vous

Rendre le protocole bidirectionnel et piloté par événements a donné à l'outillage des fonctionnalités de la classe CDP — journaux, interception réseau, concurrence — sans renoncer à la portée multi-navigateurs.

La coécriture au W3C avec Chromium signifiait qu'aucun fournisseur unique ne possédait le protocole ; Firefox ne maintenait plus un protocole privé écrit pour les DevTools de Chrome.

Parce que Puppeteer a conservé CDP comme défaut de Chrome, les automatisations existantes sont restées intactes tandis que son support de Firefox reposait sur la norme — la bibliothèque de Google livrait gratuitement la compatibilité de Mozilla.

Une fois BiDi parvenu à la parité fonctionnelle dans Puppeteer, Firefox pouvait déprécier son sous-ensemble CDP et sa charge de maintenance, laissant la norme comme seule voie d'avenir.

Quand un rival possède le protocole de facto, ne le clonez pas et ne le combattez pas — coécrivez une norme publique que les deux moteurs implémentent, et l'outil dominant devient votre canal de distribution.

Firefox 129 a déprécié CDP dès son arrivée, avec un retrait prévu pour la fin 2024, et les deux équipes ont demandé aux utilisateurs de migrer ou de signaler les API manquantes. Certaines capacités de Puppeteer n'ont pas fait le saut — les appels spécifiques à CDPSession, les instantanés de l'arbre d'accessibilité et l'évaluation dans les workers nécessitent encore des travaux de normalisation — et les équipes ont publié la liste ouverte. Une semaine plus tôt, BrowserStack avait déclaré WebDriver BiDi prêt pour la production dans son cloud, dans une période où le protocole passait de la spécification à une infrastructure multi-navigateurs livrée.