search

WICG / webhid

Web API for accessing Human Interface Devices (HID)
Other
142 stars 35 forks source link

Delay the permission request until a matching device is connected #106

Open nondebug opened 1 year ago

nondebug commented 1 year ago

Script can request access to new devices by calling navigator.hid.requestDevice. In the typical case, script passes a list of filters to requestDevice that restricts the devices presented to the user. If there are no connected devices that match the filters, an empty dialog is displayed. The user can either connect a matching device or dismiss the dialog.

As noted in #105, displaying an empty permission dialog is a poor user experience. In most cases it's better to not display the dialog at all if there are no matching devices. However, we should not allow requestDevice to automatically return early because script can use this behavior to infer information about devices it does not have permission to access.

I propose a new method for this use case:

void registerDeviceInterest(HIDDeviceRequestOptions options);

navigator.hid.registerDeviceInterest accepts the same options and filters as requestDevice, but instead of opening the permission request dialog immediately it waits until there is at least one matching device. Once the device is connected, a dialog is shown giving the user the opportunity to grant permission. If permission is granted, a connect event is dispatched for the device. If permission is not granted, no event is dispatched.

codembed commented 1 year ago

Given requestDevice (and similar calls for Serial and USB APIs) is only dispatched after a valid "user gesture", how would this delayed dialog work?

nondebug commented 1 year ago

I'm not sure exactly how this should work w.r.t. user activation. This feature would be most useful if a site could register interest without user activation so that sites can register interest as soon as the page loads without distracting the user when the device is not present.

The goal of requiring user activation is to prevent abuse of API behaviors that could be annoying to users, like creating popup windows or displaying unnecessary permission prompts. The device chooser dialog is large and partially obscures the content pane, so we should be careful about showing it without a user activation. However, it might be possible for the browser to show a less obtrusive indicator like a location bar icon when showing the chooser dialog would be too annoying. (Clicking the icon would open the chooser dialog.)

In general, I think it's fine for pages to show the device chooser dialog without a user activation if there's some other signal that the permission prompt is likely to be relevant. In this case we have a filter set that describes the type of devices the app wants, and we have a set of connected devices from the operating system, and we only show the dialog if there's overlap. That seems fine as long as the filters are sufficiently precise, we just need to define a heuristic for what "sufficiently precise" means.

I'm not sure how to handle interest in multiple devices. Suppose there is a streaming game service that wants to connect to multiple gamepads using WebHID. Can it use the same registerDeviceInterest call to be repeatedly notified each time a new gamepad is connected? Or does it need to call registerDeviceInterest again for each device?