Don't allow updates on hidden documents

[rektide]

Hello,

It'd be nice if there were some way to get the gamepad state when a window is in the background. SetTimeout and setInterval clamping effectively restricts input to once every 1s, and requestAnimationFrame isn't firing, so using the gamepad becomes basically impossible for anything but the lowest bandwidth problems as soon as the tab goes into the background.

Example use case- the Wii U model: if a bunch of people are sitting with laptops in front of a big TV (a model somewhat alike the Wii U's vidscreen controller) and a player switches out of the browser tab they are playing in (say, to go look up stats) they could still also be using the big TV screen to play the game. Except now the web page can only sample the controller at 1Hz, so most button presses will probably end up ignored and joystick control will be extremely janky.

Somewhat aside, overall I've been left with the feeling that while looping via RAF and sampling the gamepad objects is a convenient, sensible option for most developers, there's a large body of advanced topics that would benefit greatly from an evented/async model tied to the controllers natural readout and button events. Most HID devices tend to operate at at least 125 Hz and rather than sample that at arbitrary intervals, it would be great to have direct access to that stream. Certainly that kind of evented model could also be one possible option for fixing this issue. A way to fix that issue that doesn't involve Web USB. 👺

[luser]

We definitely want to spec an event-based API at some point, it just needs someone to spend the time on it.

I don't believe it's mentioned in the spec, but the implementation in Firefox intentionally does not provide updated data to non-visible web content, to minimize the risk of information leakage. It's probably fairly minimal right now, but I can imagine a scenario where we add more complex controller data to the API and it becomes a serious issue. For example, a paper published several years ago showed it was possible to use the accelerometer APIs exposed by a phone browser sitting on the same surface as a keyboard to recover keystrokes! If we expose accelerometer data from gamepads then we're vulnerable to the same attack.

Your proposed use case is definitely interesting, I'm intrigued by multi-screen gaming myself, but I'm not sure that making that example work is compelling enough to go down the road of potential information leakage. Just as a counterpoint, if the player is looking up stats in another tab, wouldn't they be using their hands to drive the laptop keyboard and not be simultaneously working the gamepad? That feels sort of contrived.

[rektide]

Another possible use case where someone would want to continue accessing the gamepad while a tab is in the background- audio. A user might be controlling a synth from a gamepad, using only audio feedback. If they switched off the tab and suddenly lost control of the synth, that could be unexpected and undesireable.

I thought of this usecase reading the discussion of Chrome limiting timer usage in background tabs- https://tech.slashdot.org/story/17/01/25/1359214/chrome-to-introduce-timer-to-throttle-background-pages

[beidson]

WebKit doesn't send gamepad input to anything but the frontmost tab of the frontmost window, and we're unlikely to change that.

[marcoscaceres]

Will add this to the spec. We can do this as part of #149.