Skip to content
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

Clarifications for getGamepads / user activations #72

Open
tomrittervg opened this issue Jun 1, 2018 · 3 comments · May be fixed by #107
Open

Clarifications for getGamepads / user activations #72

tomrittervg opened this issue Jun 1, 2018 · 3 comments · May be fixed by #107
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. wide review

Comments

@tomrittervg
Copy link

a) Why, in the example, is there a leading 'null'? Is it indicating
there are two gamepads but not giving you information about the first
one? Why?

b) "Gamepads MUST only appear in the list if they are currently
connected to the user agent, and at least one device has been
interacted with by the user." - that's great. But what does
"interacted with by the user" mean? Ever since process start? For this
origin?

@nondebug
Copy link
Collaborator

nondebug commented Jun 1, 2018

For a):

If a gamepad is disconnected, previously assigned indices MUST NOT be reassigned to gamepads that continue to be connected.

A gamepad should preserve its index in the array returned by getGamepads. Suppose the user connects an Xbox 360 gamepad over USB, then pairs a DS4 over Bluetooth, then unplugs the Xbox 360 gamepad. If getGamepads tried to avoid leaving a null element in the array, it means that any page using gamepad input would need to move the DS4 from slot 1 to slot 0. If the connected gamepad's slot has meaning in the application (eg, different gamepads correspond to different players), switching the slot unexpectedly could cause confusion and frustration.

For b), I think the spec should be clarified. In my opinion, the "interacted-with" bit should only be set if the interaction is significant (it should not be triggered when an analog gamepad is gently set onto a table or if a button is lightly touched) and should persist at the very least across a refresh but definitely not across origins. Button.pressed is probably too sensitive to be used as an "interacted-with" signal since it can fire if an analog trigger is lightly pulled.

@LJWatson LJWatson added wide review security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. labels Jun 4, 2018
@npdoty npdoty added the privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. label Jun 7, 2018
@npdoty
Copy link

npdoty commented Jun 9, 2018

+1 for more explicitly scoping the user interaction necessary for making the presence of gamepads clear. Describing the level of user interaction, how long an interaction should count for presence of a gamepad, whether interaction on one gamepad implies presence of any other connected gamepads, whether the interaction is per origin, whether that interaction counts beyond that session -- all those seem to have some assumption by implementers/users that isn't clearly described in the spec. (Issue #71 is related.)

I think another topic along the lines of the origin scope is whether the gamepads are intended to be made visible to embedded parties or only the top-level browsing context. I think users might be surprised (and the API would be much more likely to be used primarily for background tracking) if embedded iframes could also access the configuration of connected gamepads. That said, there might be larger embedded iframes that are the games themselves.

@cvan
Copy link
Contributor

cvan commented Jun 29, 2018

@npdoty: very good points. see my brief comment in #71 about possibly using the Feature Policy: #71 (comment)

@marcoscaceres marcoscaceres added the security-needs-resolution Issue the security Group has raised and looks for a response on. label Sep 9, 2021
@marcoscaceres marcoscaceres removed the security-needs-resolution Issue the security Group has raised and looks for a response on. label Oct 4, 2021
@marcoscaceres marcoscaceres changed the title Clarifications for getGamepads Clarifications for getGamepads / user activations Jan 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. wide review
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants