[gamepad] The API is not thread-safe and can not be fixed. (#18)

With smart TVs, games consoles, Android boxes and so on, lots of users are using joypads and remote controls to browse the Web. It's pretty clumsy, but when you only want to find an album on YouTube, it works.

On the OUYA, buttons and axes are mapped to browser controls. FireFox on Android maps the shoulder buttons to Back and Forward, and the left axes pan the page. Chromium is similar. I'm not sure the vendors intended for that, but still.

The issue is that the browser, extensions and webapps all want to use the same pad, but the API provides no way to 'take' or 'free' a pad.

Once an app has access to a joypad, the browser will (must) just ignore the state of the pad for so long as the app can reference that pad. It can become impossible for the user to exit an app when the only input device they have to hand must be completely ignored by the browser. Users often want to keep the app open too.

The thing is, the remote controls on smartTVs are also likely to become more like gamepads. You can't play games on a typical TV remote. In a few years, using 'gamepads' to control a browser could be as ordinary as mobile or desktop. TV-friendly sites are almost inevitable, but TV-friendly browsers are impossible, because that would break all the games that use the Gamepad API.

Currently, no extension or browser can respond to a remote control without conflicting with any other extension that does so, and the Web. To the extent that we can't break the Gamepad API, we can never use control pads in extensions, or use them to control the browser.

Unless something very clever can be done (which I don't think it can, because the issue is fundamental), the Gamepad API will need to be deprecated. We can't allow billions of TV users to have a clunky or unworkable experience to save the current Gamepad API.

If the API is not removed from each browser's Extensions API, then the first extension that uses it will break all the games that use the API for every user of the extension. The current API seems to work
because it assumes that no one will ever use the Gamepad API in an extension. As soon as people do, the games will break. If an extension maps X to Refresh Page, then any game that maps X to Fire Rocket will not work for any user of the extension. The game will still fire the rocket, but the extension will also refresh the page. The API is not thread-safe, despite different 'threads' having access to the same physical pad at the same time.

Even if the API is removed from extensions, browsers can never offer first-class support for remote controls for the exact same reason as extensions. If extensions and browsers can not respond to remote controls, then they are not able to take direct input from the user of a TV.

I have ideas for how to fix it, but there are lots of clever people that will have their own take on this once they understand the issue, so I'll save my stuff for now. The point is that none of the ideas are going to be backwards-compatible, so there is some urgency here.

I am sorry if this all comes across as a bit loud. I had a heated exchange in email yesterday with someone who took a lot of convincing, so perhaps I expect more push-back than I should.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/18