A Mozilla tornou o suporte do Puppeteer ao Firefox um padrão, não um clone do CDP

Desenvolvedores web testam rotineiramente um mesmo aplicativo em vários navegadores, e a automação por muito tempo forçou uma escolha. A API clássica W3C WebDriver alcança todos os navegadores, mas fala em requisição–resposta HTTP: carregar uma página, executar um comando, esperar a resposta. Ela não consegue transmitir logs do console ou tráfego de rede em fluxo contínuo, e executa comandos um de cada vez. A alternativa rica — o DevTools Protocol (CDP) do Chrome ou o antigo Remote Debugging Protocol do Firefox — funcionava apenas em seu próprio navegador, de modo que o autor de uma ferramenta mantinha um protocolo por engine. Pesquisas citavam os testes entre navegadores como um dos maiores pontos de dor da web.

O caminho de menor resistência era o do Chrome. O Puppeteer, a biblioteca de automação dominante, cresceu sobre o CDP, e quando ganhou suporte experimental ao Firefox em 2019 a Mozilla fez o que parecia natural: implementou e manteve um subconjunto do CDP dentro do Firefox. Isso tornou o Firefox um seguidor permanente. O CDP existe para servir ao DevTools do Chrome e muda conforme as necessidades do Chrome; não é uma especificação pública; e um clone parcial jamais poderia garantir a API completa do Puppeteer, então ninguém sabia quais recursos funcionavam onde.

O contra-movimento da Mozilla aplicou a lição do Language Server Protocol vinda dos editores de código: quando toda ferramenta precisa suportar todo navegador, a solução não é copiar o protocolo do incumbente, mas tornar o conjunto rico de recursos o padrão. Com a equipe do Puppeteer e outros membros do W3C Browser Testing and Tools Working Group, ela construiu o WebDriver BiDi — os comandos do WebDriver sobre um canal WebSocket bidirecional e baseado em eventos, de modo que logs, interceptação de rede, scripts de pré-carregamento e comandos concorrentes funcionam entre navegadores. O Gecko implementou a especificação; o Chromium também a implementou.

Em agosto de 2024 a aposta se concretizou: o Firefox 129 e o Puppeteer 23 lançaram o WebDriver BiDi pronto para produção, e puppeteer.launch({ browser: 'firefox' }) deu ao Firefox a mesma experiência de desenvolvimento que o Chrome. O Firefox descontinuou seu subconjunto do CDP, com remoção prevista para o fim de 2024, e o anúncio da própria equipe do Chrome disse o mesmo: a partir da versão 23, o suporte ao Firefox roda sobre o padrão, enquanto o Chrome mantém o CDP como padrão. O padrão, não um clone, tornara-se o caminho do Firefox.

Ser coautor do protocolo rico como um padrão aberto do W3C junto ao rival — e então o próprio Puppeteer entrega o Firefox para você

Tornar o protocolo bidirecional e orientado a eventos deu às ferramentas os recursos da classe do CDP — logs, interceptação de rede, concorrência — sem abrir mão do alcance entre navegadores.

Ser coautor no W3C junto ao Chromium significou que nenhum fornecedor isolado era dono do protocolo; o Firefox não mantinha mais um protocolo privado escrito para o DevTools do Chrome.

Como o Puppeteer manteve o CDP como padrão do Chrome, as automações existentes permaneceram intactas enquanto seu suporte ao Firefox rodava sobre o padrão — a biblioteca do Google entregou a compatibilidade da Mozilla de graça.

Uma vez que o BiDi alcançou paridade de recursos no Puppeteer, o Firefox pôde descontinuar seu subconjunto do CDP e seu ônus de manutenção, deixando o padrão como o único caminho adiante.

Quando um rival é dono do protocolo de fato, não o clone nem o combata — seja coautor de um padrão público que ambas as engines implementem, e a ferramenta dominante se torna seu canal de distribuição.

O Firefox 129 descontinuou o CDP já no lançamento, com remoção prevista para o fim de 2024, e ambas as equipes pediram aos usuários que migrassem ou relatassem APIs ausentes. Alguns recursos do Puppeteer não fizeram a transição — chamadas específicas de CDPSession, instantâneos da árvore de acessibilidade e avaliação em workers ainda precisam de trabalho de padronização — e as equipes publicaram a lista aberta. Uma semana antes, a BrowserStack havia declarado o WebDriver BiDi pronto para produção em sua nuvem, parte de uma temporada em que o protocolo passou de especificação a infraestrutura entregue para testes entre navegadores.