← back to v154 · support-for-specialized-webhid-devices-on-android
conformance · v154
v154 · support-for-specialized-webhid-devices-on-android — conformance probe
6 assertions drawn from the spec. Each is a single contract the spec text makes. Pass/fail reflects what this browser executed; blocked means the contract was not run because it needs user mediation, hardware, or another unavailable precondition. Open the page in Chrome stable / canary / Firefox / Safari to compare.
0
pass
0
fail
0
blocked
6
total
| id | contract | kind | verdict | detail |
|---|---|---|---|---|
webhid-is-present |
navigator.hid exists. This is the capability check, and it is the only one of the three questions these demos ask that decides whether any code can run. spec ↗ | script | … | |
hid-exposes-getdevices-and-requestdevice |
The two entry points, one of which needs a gesture and one of which does not. A page that cannot tell them apart will call the wrong one at load. spec ↗ | script | … | |
hiddevice-carries-the-full-report-surface |
Identity, collections, both report directions and the ability to hand the permission back. A specialised device needs all of it — a headset's mute button arrives as an input report and its LED is set with an output one. spec ↗ | script | … | |
getdevices-needs-no-gesture-and-returns-a-list |
The one call a page can make on load. It returns only already-permitted devices, so an empty array is the normal answer and must not be treated as a capability failure. spec ↗ | script | … | |
requestdevice-requires-transient-activation |
Called without a user gesture it must reject rather than showing a chooser. This is the first thing anyone hits, and the reason a page offers a button instead of asking on load. spec ↗ | script | … | |
the-platform-is-readable-separately-from-the-capability |
This feature is about a platform, so a demo has to be able to say which platform it is on — and to keep that separate from whether the API exists. User-agent client hints are the supported way to ask. spec ↗ | script | … |