-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delay the permission request until a matching device is connected #106
Comments
Given |
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 |
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:
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.
The text was updated successfully, but these errors were encountered: