- WebHID permite la comunicación con periféricos en extensiones desde Chrome 117, aunque no es compatible con navegadores en Android.
- El método requestDevice requiere un gesto del usuario, por lo que debe ejecutarse en un popup o página y no en el Service Worker.
- Las conexiones activas de HID evitan que el Service Worker se suspenda, permitiendo una gestión de hardware en segundo plano.
- Existen filtros por vendorId y usagePage, pero el navegador bloquea dispositivos genéricos como ratones o teclados estándar.
Si te apasiona el hardware y el desarrollo de extensiones, seguramente te habrás topado con la API WebHID. Básicamente, es la herramienta que permite que el navegador se entienda con periféricos de interfaz humana, como esos teclados exóticos, mandos de videojuegos o escáneres de códigos de barras, facilitando una comunicación bidireccional sin complicaciones.
Implementar esto en una extensión de Chrome tiene su miga, especialmente cuando queremos que todo funcione en segundo plano. Aunque es una funcionalidad potentísima, presenta restricciones críticas dependiendo del contexto donde se ejecute el código, lo que obliga a los desarrolladores a montar una arquitectura específica para no quedarse bloqueados.
Compatibilidad y el muro de Android
Aquí es donde vienen las primeras malas noticias. Aunque WebHID es un estándar impulsado por el W3C y funciona de lujo en versiones de Chrome 89+ y Edge en Windows, macOS y Linux, Chrome para Android no lo soporta. Tampoco lo verás en Firefox, Safari ni en Samsung Internet. El problema radica en que el sistema Android limita el acceso raw a los dispositivos USB a aplicaciones nativas con permisos específicos, por lo que el equipo de Chromium no ha podido aterrizar la API en móviles.
Si necesitas que tu aplicación web funcione en Android con HID, la alternativa es envolverla en una Trusted Web Activity (TWA), ya que intentar llamar a navigator.hid en un móvil te devolverá un undefined rotundo.
WebHID en el contexto de las Extensiones
Desde la versión 117 de Chrome, las extensiones pueden aprovechar WebHID para interactuar con el hardware de forma global. Lo mejor de todo es que no hace falta añadir permisos especiales en el archivo manifest, ya que el navegador gestiona la seguridad mediante un flujo de permiso directo con el usuario.
El problema del Service Worker
Si intentas lanzar la función requestDevice() directamente desde un Service Worker, te vas a dar un golpe contra un muro. Esta función requiere obligatoriamente un gesto del usuario (como un clic), y como el Service Worker corre en segundo plano sin interfaz, es imposible dispararlo desde ahí. No obstante, una vez que el dispositivo está vinculado, el Service Worker puede mantener la sesión abierta, evitando que el worker se suspenda mientras haya comunicación con el hardware.
Patrón de implementación correcto
Para saltarse la limitación del Service Worker, la jugada maestra es usar una página intermedia, como el popup de la extensión o la página de opciones. El flujo sería el siguiente:
- El usuario hace clic en un botón en el popup de la extensión.
- Se invoca
navigator.hid.requestDevice()filtrando por vendorId y productId. - Una vez el usuario acepta el dispositivo, el popup envía un mensaje al Service Worker mediante
chrome.runtime.sendMessage. - El Service Worker recibe el aviso y utiliza
navigator.hid.getDevices()para recuperar el dispositivo ya autorizado y ejecutar el métododevice.open().
Este baile entre la interfaz y el fondo permite que la extensión gestione el hardware de forma persistente sin violar las normas de seguridad del navegador.
Gestión de datos y reportes
La comunicación con el dispositivo se basa en reportes. Para configurar el hardware, se utilizan los Feature Reports, que permiten leer y escribir configuraciones específicas. Si lo que quieres es enviar comandos directos o recibir datos en tiempo real (como pulsar una tecla de un mando), debes usar Output Reports y Input Reports.
Para filtrar qué dispositivos queremos ver, podemos usar el usagePage. Por ejemplo, el 0x01 es para controles genéricos de escritorio (joysticks), mientras que el 0x0C se usa para controles de consumo como los botones de volumen. Es vital recordar que Chrome tiene una lista negra integrada que bloquea teclados y ratones estándar para evitar el rastreo del usuario o interferencias con el sistema.
Mantenimiento de la conexión
Es fundamental escuchar los eventos de connect y disconnect en el objeto navigator.hid. De este modo, la extensión puede reaccionar al instante si el usuario desconecta el cable USB o apaga el dispositivo Bluetooth (que, por cierto, debe estar previamente emparejado con el sistema operativo para que WebHID lo detecte).
Tener el dispositivo abierto en una pestaña o proceso bloquea el acceso a otros; solo un contexto puede poseer el handle del dispositivo a la vez. Por eso, es buena práctica cerrar la conexión con device.close() cuando ya no sea necesaria.
Dominar WebHID requiere entender que, aunque es una herramienta increíble para conectar el mundo físico con la web, depende totalmente de que el usuario dé el visto bueno inicial desde una interfaz visible. Mientras que en escritorio es un camino despejado, en Android sigue siendo una asignatura pendiente que obliga a buscar soluciones híbridas o nativas para lograr la misma interactividad.