This issue was raised in discussions on immersive-web/webxr#692 and was requested to be tracked separately.
The current spec is defined such that XRInputSources are designated to have a single primary input that will trigger the select, select-start and select-end events. Additionally, some XRInputSources may have their gamepad attribute populated with a Gamepad that has buttons, touchpads, and thumbsticks. Other than the gamepad component designated as primary, none of these other components are spec'd to fire events.
This issue tracks deciding if that is something we'd like to change and which approach to take. There may be others, but the following three are the current approaches under discussion:
Fire select events for all buttons on a Gamepad and add a buttonIndex to the select events indicating which button caused the event. The downside of this approach is that developers who only care about a primary select will get events for additional gamepad buttons they don't care about. The upside of this approach is it introduces very little additional API surface area.
Create new events to be registered for gamepad buttons. When the primary button is pressed, it would fire the originally designed select events as well as the new events. When other buttons are pressed, only the new events would be fired. The downside to this approach is that it would be a lot more spec text and design work. The upside is that it provides a clear signal that only developers who care about would listen to.
Try to coordinate with the Gamepad API which is considering events in a future api version. The downside is that the timelines for when this would be available seem unclear and potentially far off. The upside is that we wouldn't have to parallel mechanisms that behave differently based on where the Gamepad was retrieved from. This approach was originally ruled out in immersive-web/webxr#551
This issue was raised in discussions on immersive-web/webxr#692 and was requested to be tracked separately.
The current spec is defined such that
XRInputSource
s are designated to have a single primary input that will trigger theselect
,select-start
andselect-end
events. Additionally, someXRInputSources
may have theirgamepad
attribute populated with aGamepad
that has buttons, touchpads, and thumbsticks. Other than the gamepad component designated as primary, none of these other components are spec'd to fire events.This issue tracks deciding if that is something we'd like to change and which approach to take. There may be others, but the following three are the current approaches under discussion:
buttonIndex
to the select events indicating which button caused the event. The downside of this approach is that developers who only care about a primary select will get events for additional gamepad buttons they don't care about. The upside of this approach is it introduces very little additional API surface area.