bug 604039 covers prototyping a way for web content to receive input from Joystick/gamepad controllers connected to a computer.

Initial Implementation

The patches currently on the bug implement a simple set of DOM events:

MozJoyButtonDown
MozJoyButtonUp
- These events currently have the properties:
- unsigned long joystickID: an arbitrary integer ID that's unique per connected device
- unsigned long button: button number being pressed/released
MozJoyAxisMove
- This event currently has the properties:
- unsigned long joystickID: an arbitrary integer ID that's unique per connected device
- unsigned long axis: axis number being moved
- float value: position of the axis in the range -1.0...1.0

Design considerations

Should feel web-native.
- DOM Events were chosen for the first prototype implementation because of the similarity to keyboard/mouse input.
- Whatever API is chosen, it should use standard web idioms.
Should not expose the user to unnecessary fingerprinting.
- Web pages should not be able to query for the number and type of attached devices without explicit user input.
- Ideally we wouldn't have to use a permission infobar like with some other APIs, the user explicitly interacting with their device while viewing a webpage ought to be enough "permission" to send device data to that page.
- The prototype implementation falls down a bit here, it sends events to all pages that ask for them, should really be just the foreground page.
Needs to be performant for web games that want to run at 60FPS
- This will need experimentation and testing
- There are assertions that DOM events won't scale to this level, it's possible that the API will need to be changed if that is true
To be useful, will need some way to map buttons/axes to meaningful values.
- Even the same gamepad looks different on different OSes!
- Across multiple devices this is insanity
- Should try to expose enough info to let content handle this, Kevin Gadd has an "Input Device API" that is higher-level and might be a good fit here.