Re: [w3c/gamepad] id field in gamepad might have a persistent identifier? (#73)

> We could then look at minting session-based identifiers for devices on a per origin basis (could just be 1-N). That would allow connection/disconnection of game pads, while providing a stable identifier for each game pad.

I like this idea since it could help solve the enumeration persistence issue. The ID's can be mapped to enumerated slots on a first-come, first-served basis lending a reasonable amount of stability for controllers to disconnect and reconnect.

>Maybe simply disallowing Gamepad access in third-party iframes would be sufficient? The spec was written with the intent being that only pages that were visible while the user interacted with a gamepad (like pressing a button) should get access to gamepads at all so I don't think this is unreasonable. In that case I think getGamepads() ought to just return an empty array.

I have an existing use case in which this change will render the tool useless. http://gamepadviewer.com relies on the fact that a window is not currently focused to display user inputs on-screen for streaming/recording purposes. If the API is inaccessible due do a window not being in focus, this completely destroys the ability for any kind of controller display using the API.

The most typical use case is embedding controllers via Open Broadcaser's browser source component (which is a CEF plugin) but I'm unsure if accessing it via that manner reports to the page that it is currently in focus all the time.

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