Quien ha trabajado con Claude en Chrome para automatizar navegadores sabe que los clics fallan con una frecuencia desconcertante. El cursor se desvía ligeramente a la derecha del elemento deseado, las capturas de pantalla cambian de tamaño al instante siguiente y los dobles clics nunca activan el modo edición. Durante meses, muchos desarrolladores han atribuido estos fallos a elementos HTML mal diseñados o a animaciones impredecibles. Sin embargo, el problema real es mucho más profundo y se reduce a dos causas perfectamente demostrables que afectan a cualquier herramienta de automatización basada en coordenadas.
La primera causa tiene que ver con el momento en que el navegador reporta su tamaño real. Cuando una página carga, el valor de innerWidth no es definitivo. En pruebas realizadas en un equipo con resolución 1920×1080, innerWidth comenzaba en 1664 píxeles y seguía creciendo durante dos o tres segundos después de que document.readyState indicara 'complete'. Durante ese intervalo, outerWidth y outerHeight pueden devolver cero. Si en ese momento se toma una captura de pantalla y se usan sus coordenadas para hacer clic, el clic aterriza a la derecha del objetivo. La razón es matemática: la página se ha estirado un factor de 1,15 entre la captura y el clic. Cuanto más a la derecha esté el elemento, mayor será el error. No se trata de un problema exótico de aplicaciones canvas: páginas HTML comunes con carga diferida o diseños dinámicos lo sufren igualmente. Diagnosticarlo es sencillo: basta con leer las propiedades de la ventana con javascript_tool en el momento de la interacción. Si outerWidth es cero o innerWidth cambia de una lectura a otra, el tamaño aún no se ha estabilizado. Solo cuando dos lecturas consecutivas de innerWidth coinciden y outerWidth es distinto de cero se puede actuar con seguridad.
La segunda causa es más sutil y no deja rastro en los registros. La acción double_click de la herramienta informática puede enviar los dos clics con un intervalo que supera el umbral que el sistema operativo o la aplicación interpretan como doble clic. El resultado es que la aplicación recibe dos clics simples consecutivos. En lugar de entrar en modo edición de texto, se selecciona una fila entera o no ocurre nada. El problema es que la propia herramienta cree haber ejecutado un doble clic correctamente. Los logs muestran la acción como éxito. No hay forma de detectarlo desde fuera salvo verificando visualmente el estado posterior. La solución recomendada pasa por abandonar las coordenadas siempre que sea posible. En páginas HTML normales, es preferible usar referencias a elementos mediante find (búsqueda en lenguaje natural) o read_page (árbol de accesibilidad). Al trabajar con identificadores de elementos, los clics sobreviven a cualquier cambio de diseño o de tamaño. Es el método más fiable y el que evita por completo los dos problemas mencionados. La excepción son las aplicaciones canvas o Flutter, como el editor Rive, donde no existen elementos HTML identificables. En esos casos, y solo en esos, se debe recurrir a una estrategia basada en coordenadas que combine la espera de estabilización del tamaño con un doble clic rápido y artificial. Para ello, en lugar de usar double_click, se construye un doble clic manual mediante dos acciones left_click consecutivas dentro de una misma instrucción browser_batch. Así se reduce el intervalo entre clics y se respeta el umbral del sistema. Tras cada clic, conviene ampliar la zona y verificar que se ha producido el cambio de estado esperado (selección, modo edición, resaltado). Un solo fallo no detectado descarrila toda la secuencia posterior.
Más allá de la anécdota técnica, este tipo de problemas revela las limitaciones de la automatización tradicional cuando se enfrenta a entornos dinámicos. En Q2BSTUDIO, donde desarrollamos aplicaciones a medida y soluciones de automatización para empresas, hemos aprendido que la robustez de un sistema de pruebas depende tanto de la herramienta como del conocimiento del comportamiento real del navegador. Nuestros equipos integran agentes de inteligencia artificial que monitorizan el estado de la ventana en tiempo real, ajustan los tiempos de espera según las condiciones de carga y seleccionan automáticamente entre interacciones por coordenadas o por referencias de elementos. Esta capacidad de adaptación es crítica cuando se automatizan procesos complejos que involucran múltiples páginas, formularios dinámicos o componentes canvas. Además, combinamos estas técnicas con servicios cloud (AWS y Azure) para escalar las pruebas en paralelo y con herramientas de Business Intelligence (Power BI) para visualizar la cobertura y los fallos. La ciberseguridad también juega un papel: cualquier automatización que maneje datos sensibles debe garantizar que las interacciones no comprometan la integridad del sistema. Por eso, en Q2BSTUDIO aplicamos principios de pentesting y control de accesos incluso en los entornos de testing.
En resumen, los fallos de clic en Claude en Chrome no son un misterio. La ventana que se estabiliza tarde y el doble clic que se parte en dos son problemas reales, medibles y evitables. La clave está en diagnosticar correctamente el estado del viewport antes de interactuar y en elegir el método de clic adecuado según la tecnología de la aplicación. Para la mayoría de los casos, las referencias a elementos son la solución definitiva. Para aplicaciones canvas, la combinación de espera y doble clic rápido funciona de forma fiable. Y para cualquier proyecto de automatización a gran escala, contar con un enfoque profesional que contemple estas variables marca la diferencia entre un sistema que funciona a medias y uno que realmente acelera el desarrollo. En Q2BSTUDIO, integramos todo este conocimiento en nuestras soluciones de software a medida, ayudando a empresas a construir procesos automatizados robustos, escalables y seguros.
