6 puntos por xguru 2024-08-08 | 1 comentarios | Compartir por WhatsApp
  • Desde la versión 23, Puppeteer ofrece soporte oficial para Firefox, por lo que ahora es posible realizar automatización y pruebas end-to-end fácilmente tanto en Chrome como en Firefox
    • const browser = await puppeteer.launch({browser: "firefox"});
  • Al igual que con Chrome, Puppeteer puede descargar y ejecutar la versión estable más reciente de Firefox
  • El soporte para Firefox se basa en WebDriver BiDi, un protocolo multiplataforma entre navegadores ya implementado en Gecko y Chromium, y no en un protocolo de automatización exclusivo de Firefox
    • Usar un protocolo multiplataforma permitirá dar soporte más fácilmente a más navegadores en el futuro

Contexto técnico

  • Hasta hace poco, quienes querían automatización de navegadores tenían dos opciones principales
    • Usar la API WebDriver de la W3C
    • Usar APIs exclusivas de cada navegador (Chrome DevTools Protocol, Firefox Remote Debugging Protocol, etc.)
  • Ambas opciones implicaban compromisos importantes
    • La API WebDriver clásica está basada en HTTP y sigue un modelo de enviar comandos al navegador y esperar la respuesta
    • Esto funciona bien para escenarios de automatización como cargar una página y verificar si se muestra un elemento, pero no es adecuado para casos de uso avanzados como recibir eventos del navegador o ejecutar varios comandos al mismo tiempo
    • Las APIs específicas de cada navegador suelen estar diseñadas para soportar casos de uso complejos de las herramientas de desarrollador dentro del navegador, por lo que ofrecen un conjunto de funciones mucho más avanzado que WebDriver
  • Por eso, los clientes de automatización de navegadores tenían que elegir entre usar un solo protocolo para soportar varios navegadores con un conjunto de funciones limitado, o bien ofrecer un conjunto de funciones más rico pero implementando capacidades por separado para cada navegador soportado
  • Esto aumentaba el costo y la complejidad de crear una automatización multiplataforma de alta calidad
  • La situación era parecida a la de antes de que existiera LSP (Language Server Protocol)
  • WebDriver BiDi lleva a un protocolo estandarizado el conjunto de funciones de automatización que antes estaba limitado a protocolos específicos de cada navegador, para que pueda usarse en todos los navegadores y herramientas de automatización

Eliminación del soporte experimental de CDP (Chrome DevTools Protocol) en Firefox

  • Como parte de los primeros esfuerzos para mejorar las pruebas multiplataforma entre navegadores, se ofreció una implementación parcial de CDP limitada a algunos comandos y eventos necesarios para soportar casos de uso de testing
  • Sin embargo, al quedar claro que ese no era el rumbo para avanzar en la automatización multiplataforma, se detuvo el trabajo en esa línea
  • Como resultado, dejó de mantenerse y no es compatible con funciones modernas de Firefox como el aislamiento de sitios
  • Por ello, el soporte será eliminado a finales de 2024

Planes a futuro

  • Aún hay algunas APIs que siguen sin estar soportadas
    • APIs exclusivas de CDP
    • APIs que requieren trabajo adicional de estandarización
    • APIs que ya están estandarizadas, pero todavía no se han implementado
  • Se definirán las prioridades a partir de la retroalimentación de los usuarios

1 comentarios

 
xguru 2024-08-09

Comentarios de Hacker News

  • Que el equipo de Puppeteer dejara Google y se fuera a Microsoft para seguir desarrollando Playwright fue un golpe fuerte para Google

    • Google no se dio cuenta de lo importante que son las herramientas de automatización de navegadores para la estrategia de agentes de IA
    • Google tuvo que abandonar Puppeteer y depender de MS/Playwright, o encontrar un nuevo camino para Puppeteer
    • WebDriver BiDi desarrolla de forma estandarizada las ventajas de Chrome DevTools Protocol (CDP)
  • Aunque el protocolo WebDriver BiDi no es un protocolo para crear navegadores, parece que podría cumplir ese papel en casi un 90%

    • Gecko ha avanzado mucho desde Servo, y hoy en día tiene un rendimiento bastante bueno
    • Es mucho más fácil crear un navegador basado en Chromium que uno basado en Gecko
    • Con la API se pueden hacer navegación, interceptación de solicitudes, lectura de consola, ejecución de JS, etc.
    • Sería bueno poder quitar el chrome del navegador y crear un navegador personalizado
  • Playwright es compatible con todos los motores de renderizado modernos (Chromium, WebKit, Firefox)

  • Tengo curiosidad sobre el árbol de accesibilidad

    • La razón por la que se eliminó el árbol de accesibilidad en Playwright es que era un volcado de estructuras de datos internas que variaban según el motor
    • El árbol de accesibilidad resume todos los elementos semánticos de la página, y es excelente para pruebas de snapshot o pruebas BDD
    • Ojalá el árbol de accesibilidad se estandarice en los principales motores de navegador
    • Desde la perspectiva del desarrollo web, también sería bueno poder acceder a él desde otras capas como CSS y el DOM