The Gamepad API assumes you aren't using the gamepad.

Carl Smith carl.input at gmail.com
Sun Oct 25 01:13:28 UTC 2015


I've been looking at the Gamepad API. It's a nice API, and the scope is
sensibly narrow, but I think it is just too limited.

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 be difficult 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 problem is a lot like the problem of pages using bindings that
conflict​ ​with the browser, only here, you have less keys, and the browser
must let​ ​the page take over all the bindings.

The Gamepad API should allow each pad to be 'taken' and 'dropped'.

I'd suggest using a stack, with the browser always on the bottom. If an
app calls `gamepad.take` it goes on the stack. It gets popped when it
calls `gamepad.drop`. Whoever's on the top of a pad's stack has the
pad all to itself.

With a stack, for example, a browser extension could take the pad from
the browser, and a game could then take the pad from the extension. The
game could drop the pad once it was done, automatically returning the pad
to the extension. The game wouldn't need to expect the extension.

There'd need to be some place to attach two callbacks, so programs could
handle the pad being taken and returned to them.

No app *should* ever try and take the pad in the callback for when it's
taken from them, but bad code might hog a pad or get into a fight over it.
In any case, I think there should have always been a required, reserved
'menu' button on every mapping that the user can use open the browser
menu. From there, they could close tabs etc.

If something like this were to happen, browsers would need to support pads
properly, at least allowing gamepad configs to be added by the user that
would map ​'​​actions' to browser controls.​​

The browser would ideally abstract actions - stuff like taps, double-taps,
long-presses and combos (hold X and do Left, Right, Left)​, though
​extensions
could handle that stuff if the ​Gamepad ​API ​were better (and all the
browser
actions are exposed to extensions).

I tried building something with the Gamepad API and couldn't, so just
wanted to offer some feedback really.

One other thing: The inability of apps and extensions to grab the mouse
​prevents using an analogue stick to point and click.​ ​That's​ ​another​
​thing that can only be fixed at the browser level.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151025/be983223/attachment.html>


More information about the es-discuss mailing list