Mozilla convirtió el soporte de Firefox en Puppeteer en un estándar, no en un clon de CDP

Los desarrolladores web prueban rutinariamente una misma aplicación en varios navegadores, y la automatización obligó durante mucho tiempo a elegir. La clásica API W3C WebDriver llega a todos los navegadores, pero habla en petición-respuesta HTTP: cargar una página, ejecutar un comando, esperar la respuesta. No puede transmitir en flujo los registros de consola ni el tráfico de red, y ejecuta los comandos de uno en uno. La alternativa rica —el Protocolo DevTools (CDP) de Chrome o el antiguo Protocolo de Depuración Remota de Firefox— solo funcionaba en su propio navegador, así que el autor de una herramienta mantenía un protocolo por motor. Las encuestas citaban las pruebas entre navegadores como uno de los mayores puntos de dolor de la web.

El camino de menor resistencia era el de Chrome. Puppeteer, la biblioteca de automatización dominante, creció con CDP, y cuando en 2019 obtuvo soporte experimental para Firefox, Mozilla hizo lo que parecía natural: implementó y mantuvo dentro de Firefox un subconjunto de CDP. Eso convirtió a Firefox en un seguidor permanente. CDP existe para servir a las DevTools de Chrome y cambia según las necesidades de Chrome; no es una especificación pública; y un clon parcial nunca podría garantizar la API completa de Puppeteer, así que nadie sabía qué funciones funcionaban y dónde.

La contrajugada de Mozilla aplicó la lección del Protocolo de Servidor de Lenguaje de los editores de código: cuando cada herramienta debe soportar cada navegador, la solución no es copiar el protocolo del incumbente, sino convertir el conjunto rico de funciones en el estándar. Con el equipo de Puppeteer y otros miembros del Grupo de Trabajo de Pruebas y Herramientas de Navegador del W3C construyó WebDriver BiDi: los comandos de WebDriver sobre un canal WebSocket bidireccional y basado en eventos, de modo que los registros, la interceptación de red, los scripts de precarga y los comandos concurrentes funcionan en todos los navegadores. Gecko implementó la especificación; Chromium también la implementó.

Para agosto de 2024 la apuesta había dado resultado: Firefox 129 y Puppeteer 23 lanzaron WebDriver BiDi listo para producción, y puppeteer.launch({ browser: 'firefox' }) dio a Firefox la misma experiencia de desarrollo que a Chrome. Firefox dejó obsoleto su subconjunto de CDP, con retirada prevista para finales de 2024, y el anuncio del propio equipo de Chrome dijo lo mismo: desde la versión 23, el soporte de Firefox funciona sobre el estándar mientras Chrome mantiene CDP como su opción predeterminada. El estándar, no un clon, se había convertido en la vía de entrada de Firefox.

Coescribir el protocolo rico como un estándar abierto del W3C con el rival — y luego su propio Puppeteer incluye Firefox por ti

Hacer el protocolo bidireccional y basado en eventos dio a las herramientas funciones de la clase de CDP —registros, interceptación de red, concurrencia— sin renunciar al alcance entre navegadores.

Coescribir en el W3C con Chromium significó que ningún proveedor fuera dueño del protocolo; Firefox ya no mantenía un protocolo privado escrito para las DevTools de Chrome.

Como Puppeteer mantuvo CDP como opción predeterminada de Chrome, las automatizaciones existentes quedaron intactas mientras su soporte de Firefox funcionaba sobre el estándar: la biblioteca de Google distribuyó gratis la compatibilidad de Mozilla.

Una vez que BiDi alcanzó la paridad de funciones en Puppeteer, Firefox pudo dejar obsoleto su subconjunto de CDP y su carga de mantenimiento, dejando el estándar como único camino hacia adelante.

Cuando un rival es dueño del protocolo de facto, no lo clones ni luches contra él: coescribe un estándar público que ambos motores implementen, y la herramienta dominante se convierte en tu canal de distribución.

Firefox 129 dejó obsoleto CDP al llegar, con retirada prevista para finales de 2024, y ambos equipos pidieron a los usuarios migrar o informar de las API faltantes. Algunas capacidades de Puppeteer no dieron el salto —las llamadas específicas de CDPSession, las instantáneas del árbol de accesibilidad y la evaluación en workers aún necesitan trabajo de estandarización— y los equipos publicaron la lista abierta. Una semana antes, BrowserStack había declarado WebDriver BiDi listo para producción en su nube, parte de una temporada en la que el protocolo pasó de especificación a infraestructura entregada para todos los navegadores.