@kevthecoder Thanks, though that isn't a Candidate Recommendation, it's a Draft, so it's not standardized yet.

So this will need to wait for #1997 to be implemented first.

Thanks @Pauan , sounds like a plan.

I've had to disable some properties in the WebIDL for XRWebGLLayer to get the bindings to work, otherwise the build command throws an error (with no further error message). The constructor for XRWebGLLayer needed to be moved to the top level to produce bindings for XRWebGLLayer::new().

I've also had to apply a workaround for attributes marked with FrozenArray, see https://bugzilla.mozilla.org/show_bug.cgi?id=1236777 for more details.

All alterations are commented with a TODO to keep track of them.

Note that it's a draft, but also it's been shipped in multiple browsers now.

@Manishearth Do you have any evidence for that? As far as I know, only one engine supports it, and even then it requires the user to enable an experimental flag, it is not enabled by default. I have verified this by testing in both Chrome and Firefox.

I'm very confused why everybody seems to think this is a widely implemented API.

@Pauan You don't need a flag to use it in Chrome (but it only works for some devices). It's shipped on Oculus Browser and Chrome, and Firefox Reality is shipping the same API very soon. Firefox planned to ship in December along with Chrome, but some issues cropped up on the Firefox side delaying it a bit.

Either way, the editors consider the API surface done (and we're gunning for CR soon, but the process takes time), and it would be extremely unlikely for any further changes to be breaking given that there is real world content using this API now. New APIs may of course be tacked on, but that's true of all web specs.

Basically: if the main concern is breaking changes, I wouldn't be too concerned. If the main concern is just not having anything that's not gone through the full w3c standards pipeline, that's understandable.

@Manishearth Ah, I see, that explains why it wasn't working for me. In that case we should consider stabilizing XR.

Want to rebase this on #1997 and we should be able to merge then?

Want to rebase this on #1997 and we should be able to merge then?

No problem, but might be a few days before I get the time. I've been trying to improve the example code too.

Just a note that the process of generating WebIDL will change after #2012 lands.

Since #2012 has landed now, the process for generating WebIDL is:

1. Put any unstable WebIDL files into the crates/web-sys/webidls/unstable folder.

2. Run this command:

   cargo run --release --package wasm-bindgen-webidl crates/web-sys/webidls crates/web-sys/src/features
   

3. Copy the crates/web-sys/features file into the crates/web-sys/Cargo.toml file (right underneath [features]).

4. Use git add crates/web-sys to add all the generated files into git.

@Pauan @alexcrichton the code is updated to compatible with #2012 now. I like the new system, found it much easier to debug a webidl issue I was having with XrWebGlLayer.

I've tested the new bindings on a WebXr game engine project and they seem to work fine. I tried to make a simplified example application in examples/webxr, but there's a small issue I can't seem to fix at the moment (something to do with calling request_animation_frame). I'll try to take another look at it with a fresh pair of eyes, but at least the bindings seem to be working ok.

For testing I've been using Chrome with the Mozilla WebXr emulator plugin - https://blog.mozvr.com/webxr-emulator-extension.

So in summary, the bindings work and the example 90% works.

Nice, thanks for this! This all looks great to me, so any further iteration can happen in-repo!

Fantastic, thanks @alexcrichton.