Menu button vs. grip trigger for controllers with both

[thetuvix]

Button index 1 is listed as "Secondary Button/Grip Trigger". While the two example devices depicted below have only one of these, some controllers like Vive controllers and Windows Mixed Reality controllers have both.

What is the common intention with button index 1? Is it to generically expose whichever button/trigger is next most primary after button index 0? Or would we have some explicit preference between a Menu button and Grip button/trigger?

@toji, @Manishearth: Specifically, what are UAs intending to do for the Menu/Grip buttons on Vive/WinMR controllers?

[toji]

It was never the intent that a menu/back/app button be exposed at buttons[1]. It's really only intended for grip buttons or semantically similar inputs (the "bumper" on the Magic Leap controller, for instance, even though it sits above the primary trigger.)

Many UAs will reserve app buttons for UA-specific uses and not expose them to WebXR at all, typically using it as a dedicated button to exit the immersive experience and go back to the browser application instead of the top-level home screen. Chrome does this, as does the Oculus Browser and Firefox reality on the platforms that I've tried it. I understand that not every platform will need a dedicated button for this purpose, and in those cases the button could potentially be exposed but I would recommend that it's done at an index higher than the xr-standard reserved range. (ie: buttons[4] or higher.)

(EDIT: It would be handy to take stock of any known input devices that have a menu button but not a grip button to determine if this would be a common scenario. The ones that jump to mind immediately are Daydream and Oculus Go, but the nature of the platform in both cases necessitates that the menu button be reserved by the UA.)

[NellWaliczek]

Does immersive-web/webxr-input-profiles#78 address your concern?

[thetuvix]

@NellWaliczek: Partly, although the discussion in that issue raised a related concern around menu buttons: immersive-web/webxr-input-profiles#78 (comment)

[NellWaliczek]

Would it be acceptable to require any secondary button that isn't a grip (squeeze) be reported outside the first 4 indices?

[thetuvix]

That sounds like a great simplification to me! In looking through today's registry profiles, they all* have a "squeeze" press as buttons[1] - we should probably just standardize on that, since apps will start to assume it anyway.

* (except for https://github.com/immersive-web/webxr-input-profiles/blob/master/packages/registry/profiles/google/google-daydream.json, which has the string "touchpad" as button 1 instead of 2 - I presume that's just a bug, since it's inconsistent with its "generic-touchpad" fallback)

[NellWaliczek]

Fixed by #14