WebXR support?

[kettle11]

The WebXR Device API has shipped and is now supported in Chrome! It'd be really cool to write Rust to build WebXR experiences.

Additional Context

A previous issue was opened for this that was closed to wait until the WebXR Device API stabilized (and it's now stabilized [Edit: It is not stabilized, see below discussion] and shipped!): #1774

I left some comments on that previous issue with my findings about what needs to be done to get the WebXR IDL added.

[Pauan]

Could you give a link to the stabilized spec? I can only find the draft.

[kettle11]

You're right. There's only the W3C Working Draft: https://www.w3.org/TR/webxr/

I was blending together "shipped" and "stabilized" in my phrasing, which is my mistake as it doesn't match to the official terminology.

The WebXR Device API has shipped so I don't think there are plans for substantial near term changes to the WebXR Device API.

[Pauan]

I just tried accessing WebXR in 81.0.4000.3 (Official Build) dev (64-bit) but it doesn't seem to exist.

Are you sure that it's being shipped without needing to enable experimental flags in chrome://flags?

[kettle11]

It is shipped and on by default for Windows Mixed Reality headsets with Chrome and it's on by default for the Oculus Quest (which is super popular now) with the Oculus Browser, which is based on Chrome.

Other desktop headsets require experimental flags to be enabled, which is unfortunate.

For Oculus on desktop the following flags need to be set:
Oculus hardware support: Enabled
XR device sandboxing: Disabled

Not sure about the ones for other headsets.

[Pauan]

And just to clarify, it is enabled by default under navigator.xr? No browser prefixes?

[kettle11]

Yes, that's correct.

[Pauan]

It's disturbing to see Chrome turning into the new IE, pushing through non-standard APIs and bypassing the standards process without even bothering to use vendor prefixes.

But, that's off-topic. As far as this issue goes, I think we shouldn't officially support the API until it's implemented by more browsers.

However, I think we really should have support for unstable APIs (as described here). So we'd accept a PR implementing that.

[kettle11]

I believe Mozilla is shipping support sometime in the near months as well. I was trying to find a reference, but I can't find it quickly at the moment.

If some sort of support for unstable APIs unblocks this scenario, that would be great. At the moment I've forked wasm-bindgen, which is very much not ideal.

[alexcrichton]

Thanks for the report here! Looks like this is unstable so we can't add it to web-sys as-is. At this time I've opened #1950 about the discussion of supporting unstable WebIDL.

[kevthecoder]

I've dropped a quick update in the linked issue #1774

[jpryne]

Any chance WebXR will be supported soon? There are now 50 million VR users in the USA, and 171 million worldwide.

[Liamolucko]

Any chance WebXR will be supported soon? There are now 50 million VR users in the USA, and 171 million worldwide.

It's already supported as an unstable API, although I don't know whether it's up to date with the spec. It looks like WebXR is currently a 'Candidate Recommendation Draft', so it's advanced from a working draft but it's still not stable.