tracked-controls-webxr does not update entity position when referenceSpaceType is bounded-floor

[v5ma]

When <a-scene webxr="referenceSpaceType: bounded-floor"> is used, entities with laser-controls, oculus-touch-controls, or any component depending on tracked-controls-webxr remain stuck at world position (0, 0, 0). The controller models render at the scene origin and never move, even though the raw WebXR input source poses report correct positions.

Hand tracking via hand-tracking-controls is also affected (entity object3D.getWorldPosition() returns 0,0,0), though the third-party handy-controls library (handy-work) tracks correctly under the same bounded-floor session.

Switching to referenceSpaceType: local-floor restores normal laser-controls tracking behavior.

Expected behavior

tracked-controls-webxr should update entity position/rotation from frame.getPose(inputSource.gripSpace, referenceSpace) regardless of whether the active reference space is local-floor or bounded-floor. Both are floor-level reference spaces with the same coordinate conventions (y=0 at floor).

Actual behavior

• laser-controls entities stay at (0, 0, 0) for the entire session
• Raw XR API calls (frame.getPose(src.gripSpace, refSpace)) return correct positions
• Camera tracking works correctly (head position updates)
• handy-controls (third-party, uses targetRaySpace/gripSpace directly) tracks correctly
• Suggests tracked-controls-webxr either fails to match input sources or fails to apply poses when bounded-floor is the reference space type

Steps to reproduce

<a-scene webxr="requiredFeatures: bounded-floor, hand-tracking;
                referenceSpaceType: bounded-floor"
         renderer="stencil: true">

  <a-entity id="rig">
    <a-entity camera look-controls position="0 1.6 0"></a-entity>
    <a-entity laser-controls="hand: left"></a-entity>
    <a-entity laser-controls="hand: right"></a-entity>
  </a-entity>
</a-scene>

1. Open on Meta Quest 3 (or any device supporting bounded-floor)
2. Enter VR
3. Observe controller models stuck at floor center (0, 0, 0)
4. Change referenceSpaceType to local-floor and they track correctly

Telemetry evidence

Logged every 2 seconds during a VR session:

RAW-L ctrl raw=(0.88, 1.11, -0.77)    <-- correct XR API position
ENT-L leftController world=(0.00, 0.00, 0.00)  <-- entity never updates

RAW-R ctrl raw=(0.62, 1.10, -0.74)
ENT-R rightController world=(0.00, 0.00, 0.00)

The RAW values come from frame.getPose(src.gripSpace, renderer.xr.getReferenceSpace()) and are correct. The ENT values come from el.object3D.getWorldPosition() on the laser-controls entity and never change from origin.

Environment

• A-Frame version: 1.7.1
• Device: Meta Quest 3
• Browser: Meta Quest Browser (Chromium-based)
• OS: Quest OS v74+

Workaround

Use handy-controls from the handy-work library, which reads gripSpace and targetRaySpace poses directly rather than going through tracked-controls-webxr. This tracks correctly with bounded-floor.

Alternatively, keep referenceSpaceType: local-floor and request bounded-floor separately only to read boundsGeometry without calling renderer.xr.setReferenceSpace().

[mrxz]

Seems to be a bug in the Meta Quest browser. For whatever reason the frame.getPose(inputSource.gripSpace, refSpace) returns a null pose. This only seems to happen for bounded-floor and only for reference spaces not created immediately upon starting the XrSession.

Recentering seems to resolve the issue for all bounded-floor reference spaces. But since the tracked-controls system request a new one every time the inputs change, new ones exhibit the same problem (till a recenter/reset occurs). @v5ma Can you confirm that after recentering using the oculus button the issue is (temporarily) gone?

I've done some debugging using the following: https://krabbel.dev/p/silver-teams-hug
The scene shows 4 cubes that are green if a pose is returned and red if the pose is null. From left to right these are:

1. Using the reference space of the tracked-controls system (which exhibits the issue)
2. A bounded-floor reference space requested upon enter-vr
3. A bounded-floor reference space requested 1s after the enter-vr event
4. Using the reference space used by Three.js (renderer.xr.getReferenceSpace())

In my testing, both 1 and 3 remain red until I recenter. Whenever the input sources change, the first cube becomes red again, while the rest remains green.

[mrxz]

Confirmed to be a bug in the Meta Quest browser. A fix should land in version 146, per the following message in the WebXR Discord server.

thanks for the repro case! I found the issue and I believe it's been like this for a long time. A fix will ship in 146