Gamepad appears to be readable from multiple background tabs simultaneously
Reported by
just...@gmail.com,
Sep 1 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. html5gamepad.com 2. press a button, it should show your Gamepad 3. open another tab and html5gamepad.com 4. press a button, it should show your Gamepad 5. Go back to original tab, note that the timestamps updated What is the expected behavior? I expect that the background tab did not receive updated Gamepad data as the tab wasn't focused/active. What went wrong? I don't expect two tabs to be able to get my Gamepad input simultaneously. Other browsers, namely Edge, restrict access to the Gamepad to the active tab. I have not yet tested iframe scenarios within the same tab, but it would seem that might be broken as well. With WebVR our primary input model is a Gamepad so making sure that the input of the Gamepad is secure will be important to establishing a user trust model. Did this work before? No Chrome version: 52.0.2743.116 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0 I recall looking at this in Edge/IE years ago and I'm pretty sure at that time, the same bug existed in Chrome and Edge/IE decided to take a more restrictive approach.
,
Sep 1 2016
,
Apr 21 2017
bajones: Ping. Is it expected that background tabs can get gamepad inputs?
,
Feb 14 2018
,
Feb 14 2018
,
Feb 14 2018
bajones, mattreynolds: Any answer to the question in c#3?
,
Feb 15 2018
,
Feb 15 2018
Yes, this is expected. Gamepad inputs don't follow the focus model and are polled rather than event-based. All visible tabs can receive gamepad input even if they lack focus. This is fairly normal for gaming applications where it is sometimes desirable for an unfocused window to receive gamepad inputs. I think a truly backgrounded tab will not receive gamepad inputs, but will receive the most up-to-date gamepad state once the tab is foregrounded. This could explain why you are seeing the timestamp update for a backgrounded tab.
,
Feb 15 2018
Thanks for the update. Based on that I think it's reasonable to remove this from the security queue. If there's no additional work planned feel free to close the bug. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by elawrence@chromium.org
, Sep 1 2016