Webxr: Clarify usage of ButtonIndex
Currently the XRInputSourceEvent is only fired for select events, which should be the primary button, and per both the xr-standard mapping described in the WebXR spec and the general Gamepad spec, seems like it should always be 0 (or null if there is no Gamepad).
The buttonIndex feels like a bit of unnecessary extra data, especially if we aren't going to use XRInputSourceEvents for anything other than select (arguably what's implied by Issue #551 ).
alcooper91
All 17 comments
If the intention is that the UA should fire selectstart/select/selectend for all buttons then their usage for primary actions should be clarified (i.e. buttonIndex=0).
alcooper91
on 13 Jun 2019
The intent is for all button presses to fire the XRInputSourceEvent. Manish, could you pick up clarifying that?
cwilso
on 17 Jun 2019
It appears that new algorithm(s) are needed for generic button clicks, similar to those for selectstart, etc.
ddorwin
on 17 Jun 2019
@cwilso:
The intent is for all button presses to fire the XRInputSourceEvent. Manish, could you pick up clarifying that?
@toji: Is @cwilso's assertion correct here? My longstanding understanding of selectstart/select/selectend is that it is specifically about the input source's primary action, which may or may not involve a gamepad button. If this was intended for all gamepad buttons, it should probably be named pressdown/press/pressup or such - the term select was used to indicate that it represents the source's primary select action for proceeding in an experience.
thetuvix
on 27 Jun 2019
Yeah, I came across that issue when trying to resolve this issue.
My current plan was to create a concept of an action, and the UA can support as many as it wants, and one of them may be the primary action (buttonindex = 0).
I don't think it's super useful to have two kinds of events. Potentially have an .isPrimary() on XRInputSourceEvent though.
Manishearth
on 27 Jun 2019
I think it’s still useful to have both kinds of events, as (IIUC) the primary action is the one that actually counts as a user action for activation and I think many simple buttons would want to just blindly hook up a click handler for select and ignore other actions. Requiring a heavier weight check here feels wrong, especially since the gamepad is an extension that not all controllers have. On top of this, if a controller doesn’t have an xr-standard mapping, is it conceivable that the “primary action” would not be index 0?
We will definitely need another event name to fire the other button events though.
alcooper91
on 27 Jun 2019
We could not rely on the button index and straight up expose .isPrimary()
Manishearth
on 27 Jun 2019
I think there's still the disconnect with it being a little heavyweight for things that only care about the primary and a bit of a mismatch in expectations given that the primary is also supposed to count as a user activation.
I could see an argument for having both events and the .isPrimary(), that way a developer could choose if they only care about primary or care about all.
alcooper91
on 27 Jun 2019
@NellWaliczek any thoughts on what this should be here? I can make the simple changes to allow all button presses to generate select events (and enforce buttonIndex = 0 for the primary action, or add isPrimary()), but we might want something different here.
Manishearth
on 27 Jun 2019
sigh @toji and I were both reading the comments in this issue and thinking "yeah... this is a bit confusing as is.. but...hmmmmm" Give us a day or so to think over what would be the right way to handle it. I'm leaning slightly towards two separate events because that makes it more sense in terms of separating developer intent, my main hesitation is that the Gamepad folks are also considering adding an event system.
NellWaliczek
on 27 Jun 2019
Ah, I see. Thanks!
Manishearth
on 27 Jun 2019
I'm leaning slightly towards two separate events because that makes it more sense in terms of separating developer intent, my main hesitation is that the Gamepad folks are also considering adding an event system.
I'm leaning towards a separation of concerns on the events here as well, but the fact that there is (in theory) some parallel work happening on the gamepad side maybe suggests that we should defer the question of general button press events for a bit. If we removed buttonIndex for the current milestone we preserve our options going forward. Either supporting a second event or re-instating buttonIndex would both be additive to the API, and I would appreciate the opportunity to evaluate this more carefully prior to CR.
toji
on 27 Jun 2019
Cool, I'll go ahead and do that.
Manishearth
on 27 Jun 2019
Manishearth
on 27 Jun 2019
I'm inclined to either close this issue and open a new one tracking the desire to have gamepad button eventing OR rename this issue to reflect that. Any preference?
NellWaliczek
on 2 Jul 2019
New issue, preferably, just for cleanliness
Manishearth
on 2 Jul 2019
New issue filed. Closing this one.
NellWaliczek
on 19 Jul 2019
Related issues
NellWaliczek
·
10Comments
kintz09
·
9Comments
bwasty
·
3Comments
IoanaMereuta
·
9Comments
toji
·
6Comments
Most helpful comment
Cool, I'll go ahead and do that.