Re: [w3c/gamepad] Re-enable Gamepad Access from HTTP (aka insecure) Context (Issue #203)

> My proposal is to let the browser engine prompt the user for their permission for full access to the gamepad.

I'm generally in favor of adding a gamepad permission since that will make it possible to expose more powerful gamepad features. However, it will take significant effort to add a permission and I feel this use case is not common enough to justify the work. I hope we do add a permission eventually, but I expect it will be in conjunction with adding some powerful new capability.

We've discussed adding a permission in the past. The current API is not well suited for a permission; normally we would want an async API so we can insert a permission prompt between calling `getGamepads()` and returning a `sequence<Gamepad>`. The current API is synchronous, so even if we do show a prompt we still need to return something. If we add a permission we will probably also add a new async way to request gamepads. This could be a new method like `getGamepadsAsync()` or maybe we could add options to `getGamepads()` that modify its return value.

Something we should consider is what happens to the already-returned `Gamepad` objects when the user grants permission. Presumably there will be some attributes that expose different values when the permission is granted vs. not granted. Are the "granted" and "not granted" versions of the `Gamepad` considered the "same" `Gamepad`? If so, are the `Gamepad` attributes updated "live" or does the caller need to call `getGamepads()` again to access the extra functionality? Are pre-grant `Gamepad` objects still usable? Would we fire disconnect/connect events when transitioning between permission states?

> Full access means the full feature of the gamepad being exposed from gamepad API, even when window is not focused.

Gamepad API as specified doesn't consider window focus, only page visibility. Some implementations may have focus requirements due to the underlying operating system API used to read gamepad inputs. The OS-level API for reading gamepad inputs may deliver events only to focused applications. This behavior isn't defined as part of the spec and it's unlikely that implementations would be able to work around it without finding an alternative for the OS gamepad API.

In the Chromium implementation, different OS-level APIs are used for different types of gamepads so in some cases the focus-related behavior can differ between gamepads.

I feel gamepad inputs should not be tied to focus because it's unusual to use a gamepad and keyboard/mouse at the same time. Interfaces designed for use with gamepads typically don't have input focus, since gamepad text input is usually modal and involves an on-screen keyboard. Also, there are known use cases where it's useful for script to access gamepad inputs without focus.

> Before full access was granted, code from an insecure context may still access an abstracted controller that do not contain any device-specific information nor physical actuators

I like this idea. I agree it should be possible to expose an abstracted controller while preserving user privacy and security.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/203#issuecomment-2103569982
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/203/2103569982@github.com>