v154 · input · webhid

WebHID, on the device most people are holding

Mice, keyboards and gamepads reach the web through high-level events. Everything else with a human interface descriptor — a call-control headset, a custom keypad, a stenotype, a flight yoke, a scientific instrument — needs raw report access, and that has been desktop-only. Extending WebHID to Android puts those devices within reach of the browser people actually carry.

concepts

  1. The interface, and what it can tell you

    Every member of HID and HIDDevice read from this browser, with a live list of already-permitted devices — which is the one thing a page can ask for without a gesture.

  2. Where you are, and whether that matters

    The API's presence and the platform are separate questions, and the answer to the second decides what the first is worth. Both are measured here from user-agent client hints rather than parsed out of a string.

  3. Asking for one

    Build a filter, press the button, and watch the real call — including the failure you get without a user gesture, which is the first thing anyone hits.

why it shipped

The web has good abstractions for the three input devices everyone has. It has nothing for the long tail: the headset whose mute button is a HID usage rather than a key, the assistive keypad with a custom report layout, the industrial scanner that speaks a vendor protocol over interrupt transfers. WebHID exists for exactly those, and until now a page that needed one also needed a desktop.

Android is where a great many of those devices are used — a phone plugged into a headset, a tablet driving a point-of-sale peripheral, a handheld terminal. Supporting them there is less a new capability than the removal of an arbitrary boundary.

the API

// Requires a user gesture, and shows a chooser.
const [device] = await navigator.hid.requestDevice({
  filters: [{ vendorId: 0x1234, usagePage: 0x000b }],  // telephony
});

await device.open();
device.addEventListener("inputreport", (event) => {
  const bytes = new Uint8Array(event.data.buffer);
  // …
});

// Already-permitted devices need no gesture.
const known = await navigator.hid.getDevices();

enabling it now

WebHID itself is present on the desktop Chrome 150 these pages were built with — navigator.hid is an object with getDevices and requestDevice, and HIDDevice.prototype carries the full report surface. What could not be tested is the thing this feature actually changes, because the build machine reports formFactors: ["Desktop"] and mobile: false: whether any of it works on Android.

navigator.userAgentData.getHighEntropyValues(["formFactors", "mobile"])
// { formFactors: ["Desktop"], mobile: false, platform: "Linux", … }

So the pages measure the API surface and the platform separately, and are explicit that a desktop result says nothing about the Android one.

references