JoystickAPI

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.

Discussion

• Pages will want instantaneous state of device, we might as well expose it (may alleviate polling concerns as well)
  • Expose a joyState property on each event, content can hold on to that object and it will update live as input happens
• Not sure about mapping various devices to a sane set of controls
  • Going to try exposing a device ID for testing, collect some data and see what it looks like
  • Probably a fingerprinting concern, may not want to ship this
  • How much do we push to content vs. try to handle in the browser?
  • We'll get new try builds and put up a web page to gather data from users with various devices
• Need timestamps per event (using milliseconds like requestAnimationFrame)
• sicking is going to schedule a security review to get some more people thinking about it
• Proposal for a f6xf2P25i1NT0ilCihJuPDwYWEU/edit?hl=en US polling based API, soliciting feedback.