¿Qué es WebDriver BiDi?

Scrapeless Agent Browser proporciona sesiones de navegador gestionadas a través de interfaces de conexión documentadas para clientes de automatización de navegadores.

WebDriver BiDi es un protocolo bidireccional para controlar navegadores de forma remota y recibir eventos del navegador. “BiDi” se refiere a la comunicación en ambas direcciones: un cliente de automatización envía comandos, y el navegador puede enviar mensajes de eventos cuando ocurre una actividad suscrita. Este modelo impulsado por eventos admite observaciones que resultan incómodas de expresar solo como consultas repetidas de petición y respuesta.

WebDriver BiDi es un protocolo, no un navegador, un ejecutor de pruebas ni un servicio de alojamiento. La especificación del W3C sigue siendo un trabajo en curso, y las implementaciones pueden diferir en los módulos y comandos que admiten. Por lo tanto, una evaluación necesita el navegador real, el binding del cliente, la capacidad del protocolo y la operación requerida por la tarea, en lugar de una afirmación general de que una pila “admite BiDi”.

Qué aporta la comunicación bidireccional

La comunicación bidireccional permite que un navegador informe de la actividad relevante sin esperar a que el cliente pregunte por cada ocurrencia individual. El protocolo WebDriver BiDi define comandos, respuestas, eventos, transporte y módulos para el control y la observación del navegador.

Una interacción tradicional de petición y respuesta es suficiente para muchas acciones. El cliente solicita una navegación y recibe un resultado. La observación basada en eventos se vuelve útil cuando un navegador puede generar actividad entre esos comandos, como un documento que cambia de contexto o un script que produce una entrada de registro.

La mejora importante es el modelo de observación, no una promesa de que cada tarea del navegador se vuelva más rápida. Si una tarea solo necesita un título de página final, un flujo de eventos puede aportar poco. Si una tarea debe asociar la actividad de la consola con una navegación concreta, las suscripciones pueden proporcionar información más relevante que solicitar periódicamente una instantánea.

Los eventos también crean responsabilidades. El cliente debe decidir a qué suscribirse, cómo correlacionar mensajes, qué eventos importan para la finalización y cuándo liberar suscripciones. Una colección ilimitada de observaciones puede convertirse en un problema de almacenamiento e interpretación en lugar de diagnósticos útiles.

Los comandos, las respuestas y los eventos tienen funciones diferentes

Los comandos solicitan una operación, las respuestas informan de su resultado y los eventos describen la actividad del navegador a la que se está suscrito. Estos tipos de mensajes deben manejarse según su función en lugar de tratarse como una única lista secuencial de acciones completadas.

La respuesta de un comando puede confirmar que una operación de protocolo admitida se completó. Un evento puede llegar debido a la actividad del navegador iniciada por la página u otra operación. El cliente necesita suficiente contexto para vincular la observación con el documento, la tarea y la navegación relevantes.

No interpretes la existencia de un evento como prueba de que la aplicación ha alcanzado su objetivo de negocio. Un evento de navegación dice algo sobre la navegación. La tarea aún puede necesitar que aparezca una región de resultados, que un formulario se habilite o que se seleccione un elemento concreto.

Define un pequeño contrato de observación para la tarea. Identifica el comando que inicia el trabajo, los eventos que proporcionan evidencia útil, la condición de la página que establece el éxito y la limpieza que finaliza la observación. Esto hace que un flujo de trabajo impulsado por eventos sea revisable sin requerir que cada mensaje bruto se conserve para siempre.

La identidad del contexto importa en la automatización impulsada por eventos

La identidad del contexto determina a qué página o documento incrustado concierne un evento. Un navegador puede contener múltiples páginas de nivel superior y documentos hijos, por lo que una conexión no implica un único documento de interés.

El modelo de contexto de navegación de HTML proporciona la distinción subyacente entre los documentos de un navegador y sus relaciones. Una ventana emergente, un marco anidado y una navegación pueden afectar cada uno a qué documento se debe observar o controlar.

Un ejemplo práctico es una aplicación que abre un recibo en una página independiente. El clic que inicia la acción pertenece a la página original, pero la condición de disponibilidad del recibo pertenece al nuevo contexto. Una tarea que siga leyendo el documento original puede concluir que no existe ningún recibo aunque el navegador lo haya abierto correctamente.

La identidad de los iframes requiere una atención similar. Un mensaje de registro de un widget incrustado no debería atribuirse automáticamente a la aplicación principal. Conserva la identidad del contexto en los registros de diagnóstico para que las observaciones puedan vincularse con el documento que las produjo.

Las suscripciones necesitan alcance y duración

Una suscripción debe cubrir los eventos y contextos requeridos para una tarea, solo durante el tiempo que la tarea los necesite. Esto limita tanto el ruido de diagnóstico como la posibilidad de conservar información de páginas no relacionadas.

Establece la observación antes de la actividad cuya evidencia necesitas. Si una página puede producir un evento relevante inmediatamente después de una acción, adjuntar un observador después puede dejar un vacío. Comprueba el comportamiento real del ciclo de vida del binding del cliente en lugar de asumir que el orden se gestiona automáticamente.

Elige qué almacenar después de la recopilación. Un registro conciso de un tipo de evento, un identificador de contexto y un resultado relevante puede ser suficiente para el resumen de un trabajo. Los mensajes de registro completos o los detalles de red pueden contener datos confidenciales de la aplicación, por lo que el registro conservado debe ajustarse a la necesidad de resolución de problemas.

Cierra las suscripciones cuando su propietario termine. Un cliente de larga vida que controla varias tareas no debe adjuntar accidentalmente el observador de una tarea anterior a una tarea posterior. La propiedad explícita facilita explicar tanto las observaciones que faltan como las observaciones que aparecen en el trabajo equivocado.

WebDriver BiDi, WebDriver clásico y CDP

WebDriver BiDi, WebDriver clásico y el Protocolo de Herramientas de Desarrollo de Chrome son interfaces de control diferentes. Un uso compartido de automatización del navegador o transporte WebSocket no los hace intercambiables.

El modelo clásico de comandos de WebDriver define las operaciones remotas del navegador a través de su interfaz estandarizada. BiDi añade un modelo de protocolo bidireccional. CDP tiene su propia superficie de comandos y eventos asociada con las herramientas de Chromium. Selecciona en función de la cobertura real del navegador y de las operaciones que tu aplicación necesita.

Una migración no tiene que reemplazar todas las operaciones a la vez. Identifica la observación que requiere BiDi y luego verifica cómo el cliente elegido la combina con el control de navegador existente. Evita una reescritura a nivel de todo el protocolo cuando el requisito es una capacidad de diagnóstico limitada.

Debe evaluarse la compatibilidad del navegador por operación

La compatibilidad del navegador con WebDriver BiDi debe evaluarse por operación y entorno. Una conexión exitosa establece el transporte, mientras que una suscripción o comando compatible establece una capacidad más limitada.

La superficie del cliente Selenium BiDi proporciona contexto de implementación para aplicaciones que usan Selenium. No elimina la necesidad de verificar la combinación real de enlace de lenguaje y navegador. Una función demostrada en un lenguaje puede tener una interfaz o un estado de compatibilidad diferente en otro.

Crea una lista de comprobación de capacidades vinculada al trabajo. Para cada operación requerida, especifica el entorno del navegador, el método del cliente, el comportamiento de protocolo esperado y la condición que demostrará que funciona. Registra explícitamente las capacidades no compatibles para que un evento ausente no se diagnostique erróneamente como un resultado vacío de la aplicación.

Evita copiar antiguas flags experimentales o ejemplos de conexión sin revisar la documentación actual. El trabajo en el protocolo evoluciona, y una configuración que una vez habilitó una función en vista previa puede ya no describir la ruta compatible. Este glosario intencionalmente no proporciona código de conexión sin ejecutar ni una tabla de compatibilidad universal.

Un escenario de aceptación útil de BiDi

Un escenario de aceptación útil conecta un evento con un resultado visible en la página. En una aplicación de prueba controlada, organiza que una acción de página abra un documento conocido y emita un mensaje de diagnóstico reconocible.

Suscríbete a la categoría y al alcance de evento necesarios antes de iniciar la acción. Realiza la acción, identifica el nuevo contexto del documento e inspecciona la condición de la página de destino. La prueba solo se aprueba cuando la observación esperada pertenece al contexto esperado y el resultado de la aplicación es correcto.

También ejercita la limpieza. Finaliza la observación, realiza trabajo no relacionado y confirma que la tarea anterior no continúa acumulando evidencia. Esto comprueba la propiedad de la suscripción, que un ejemplo de caso ideal suele dejar sin examinar.

Mantén separados los resultados de protocolo y de negocio en el informe resultante. Una suscripción fallida, un contexto cerrado y un registro de página ausente necesitan explicaciones distintas. Esa distinción es especialmente valiosa en la ejecución remota, donde varias capas de infraestructura y aplicación pueden fallar de forma independiente.

Uso de conceptos BiDi con Scrapeless

Los conceptos BiDi ayudan a explicar la automatización impulsada por eventos, pero un endpoint de Scrapeless debe utilizarse a través de su protocolo documentado. La superficie de CDP de Agent Browser documenta operaciones de CDP; no es evidencia de un endpoint WebDriver BiDi.

La plataforma Agent Browser ofrece funciones de ejecución y observación de navegadores gestionadas. El análisis de diagnósticos de consola y sesión del navegador aporta contexto operativo relacionado, mientras que precios de Scrapeless ayuda a planificar la carga de trabajo. Verifica la interfaz requerida antes de traducir un concepto de protocolo en una integración de producto.

Conclusión

WebDriver BiDi convierte los eventos del navegador en parte de la conversación de control. Úsalo cuando la observación basada en eventos resuelva un requisito definido, y diseña conjuntamente la identidad de contexto, el alcance de la suscripción, las condiciones de finalización y la limpieza. La compatibilidad se establece por las operaciones que tu navegador real y tu cliente pueden realizar, más que por un nombre de protocolo por sí solo.