Address contradiction on whether XRInputSource gamepads are exposed

[msub2]

While looking over this spec in preparation for eventually updating Servo's WebXR implementation, I noticed a very clear contradiction between the intro text to the Gamepad API integration and the Navigator section. The intro text states that user agents MAY expose XRInputSource gamepads via navigator.getGamepads(), but the following section states that they MUST NOT be exposed. Looking at the git blame, it seems like the intro text change was more recent, so I think it makes sense to treat that as the ground truth.

---

Preview | Diff

[toji]

Hm... this is a bit more complex that it may appear at first.

For the record the text from the "Navigator" section has been in this repo since commit #1, so there's no obvious paper trail as to the discussion that led to it. The other text was merged in #49, which points to #19, which also is unfortunately light on discussion but at least provides some context: Browsers wanted to ability to use controllers as more traditional gamepads for non-XR content. The group agreed that this was a good idea and the text was added to support that use case.

The complication comes from this: Yes, you can show XR controllers as standard gamepads if the user agent wants to. But can you have them in the gamepads array AND as an XRInputSource on an active session at the same time? I'm inclined to say no, and I think that's what this (admittedly confusing) apparent text contradiction is trying to say.

When the text says "An XRInputSource's associated Gamepad MAY be exposed via navigator.getGamepads()" I think it's using "XRInputSource" not necessarily as an actual XRInputSource instance attached to an XRSession but as a more abstract "Input source for an XR device that may be exposed as an XRInputSource instance at some point." (Yes, that's confusing. I blame myself.) It would make sense to me to say that a controller can be exposed as a typical gamepad if the UA wants up until an XRSession is started. If the controller then shows up as an input source for that session it MUST NOT appear in the normal gamepad list until the session has ended. That way we avoid getting accidental double-processing of inputs and it's very clear which interfaces developers should be looking to in order to handle XR input.

That being said, this obviously needs some clearer text all around, and regardless of my speculating above I think the more important consideration at this point is what are implementations currently doing and how might existing content break if we make changes here. As such I think this is a great topic for our next meeting.

/agenda

[msub2]

After reading your explanation and looking over the spec again that definitely does make more sense. Perhaps a good way of making it more explicit at first glance would be to establish the input coming from the XR device as "raw input" or similar, which can then be used in the creation of a Gamepad object that can be returned either by navigator.getGamepads() or on an active XRInputSource