WebXR
Standard WebXR runs on a DisplayXR display with nothing extra installed. For web content authored for a 3D display, inline 3D in the DisplayXR Browser is the path we support.
Standard WebXR works, unmodified
Chrome speaks stock OpenXR through the loader into displayxr-service, so an ordinary immersive-vr page renders on the service compositor and out to the 3D display like any other OpenXR app. Install the runtime and existing WebXR content runs — no extension, no companion process, no page changes.
What you get is generic stereo: the browser has no concept of the physical display, so framebuffers are compromise-scaled and the eyes are fixed rather than tracked. There is no head-tracked off-axis (Kooima) projection on this path, and no rendering-mode switching. That is the ceiling of an unaugmented browser, and it is the honest floor we support.
For 3D-display-aware pages: inline 3D
Immersive is the headset's model — one exclusive session that owns the whole display. A glasses-free desk display is not used that way. Its natural model is inline 3D: a weaved element sitting inside an ordinary page, surrounded by HTML, with the rest of the web still on screen around it.
That is what the DisplayXR Browser does. It renders the web normally and asks the runtime to weave the 3D regions of the page through XR_DXR_weave — GPU-resident, no per-frame CPU readback, and no exclusive session to enter or leave.
The WebXR Bridge was retired
Through runtime v2.10 we shipped a metadata sideband: an MV3 Chrome extension that added a session.displayXR surface, fed by a companion displayxr-webxr-bridge.exe on a loopback socket. It carried display geometry, rendering modes, tracked eye poses, HUD state, and forwarded input alongside Chrome's own frames. It was removed in v2.11.
The reason is who it served. A page only benefited if it had been explicitly written against session.displayXR, so the bridge never upgraded the existing headset-authored WebXR corpus — its entire audience was developers already building for DisplayXR. Those developers are better served by inline 3D, and asking them to install a runtime, an extension, and a loopback daemon was a harder ask than installing our browser.
Stated plainly: immersive WebXR is no longer a first-class authoring target for DisplayXR. Bare WebXR keeps working exactly as described above — nothing regressed for pages that never used the bridge — but the display-aware quality tier now lives in the browser's inline-3D path instead of an immersive session.
The full rationale, and what was deliberately kept, is in runtime issue #1180.