How to WebXR in July 2018

~ 5 Minute Read.

With We­b­VR Pong I ven­tured in­to an un­fin­ished web API and since I had nev­er got­ten in touch with javascript much, I had to learn a cou­ple of things that may be nat­u­ral to the web­de­vs amongst you.

Note that I come from a We­b­VR use case and have no ex­pe­ri­ence with the AR part of We­bXR yet.


On­ly Chrome on An­droid sup­ports We­bXR “na­tive­ly” at the mo­ment. For oth­er browsers use We­bXR Poly­fill for now. It’s a lay­er on top of We­b­VR to em­u­late We­bXR un­til it is ful­ly sup­port­ed.

Ad­di­tion­al­ly use the ver­sion shim like in the We­bXR Sam­ples. It will “pro­tect” you from API changes, type/enum/func­tion re­names, so that your app doesn’t stop work­ing im­me­di­ate­ly with the next brows­er up­date—or worse, on­ly work on some browsers that sup­port the lat­est spec and not on oth­ers which are stuck on one of the ear­li­er ver­sions.

Ori­gin Tri­als To­kens

Since we are deal­ing with an un­fin­ished API, you need an “Ori­gin Tri­als To­ken”, which en­ables the API on your page for all users. This is to raise aware­ness that the API is un­sta­ble and will not be same in a cou­ple of months. So that browsers can be re­lieved from the re­spon­si­bi­ly of sup­port­ing all ver­sions while still pro­vid­ing you some im­ple­men­ta­tion to play around with, the to­ken will ex­pire on a known date.

This does not hin­der you from just en­abling e.g. chrome://flags/#webxr for just your­self. You on­ly need the to­ken to en­able the fea­ture for users with­out them hav­ing to set that flag.

For localhost, you do not need a to­ken, all fea­tures will be en­abled there by de­fault, if I un­der­stood cor­rect­ly.

Find in­for­ma­tion on how to re­quest such a to­ken here.


On Desk­top you will want to use Fire­fox to­geth­er with the Ocu­lus Rift or the HTC Vive for ex­am­ple. I found that this works very well through the We­bXR Poly­fill. (If you have any ex­pe­ri­ence with We­bXR on the Mi­cro­soft Mixed Re­al­i­ty head­sets, please let me know! Should al­so be sup­port­ed through SteamVR, though.)

To de­bug on An­droid Chrome with­out a to­ken, use the port for­ward mech­a­nism of Chrome to al­low your phone to con­nect to localhost, where the to­ken is not need­ed:

WebXR debugging with port forwarding in chrome.

You will find it in the “Re­mote De­vices” pan­el from which you can al­so get a screen­cast and the con­sole for your de­vice. Make sure Chrome is open on your de­vice aswell.

WebXR debugging remote devices in chrome.

Since a Card­board de­vice should al­ways be avail­able, as long as your phone sup­ports it, this should be suf­fi­cient.


Build­ing vir­tu­al re­al­i­ty games is su­per fun! Es­pe­cial­ly when the de­vice ab­strac­tion lay­er is han­dled for you with such a nice and sim­ple API as the We­bXR De­vice API—you can build once and it runs on all de­vices!

Un­til it doesn’t: In par­tic­u­lar I en­coun­tered a (maybe?) bug where Chrome seems to wait for gl.clear(...) as a way to de­tect whether you sent a frame or not. If you de­cide not to clear, it will show you a spin­ner on Day­dream with the mes­sage “Page is not re­spond­ing” or sim­i­lar.

Some­thing along the lines of…


// or
gl.clearColor(0.0, 0.0, 0.0, 0.0); // or any other color

… will en­sure this does not hap­pen to you.

Go Build

There are many frame­works out there, e.g A-FRAME, three.js or—if you’re in­to C++ like I am— Mag­num, that can help you build your own We­bXR dream app.

Go do so, it’s ridicu­lous­ly fun! And then play We­b­VR Pong :P

Since you’re in­ter­est­ed in We­bXR de­vel­op­ment, do please fol­low me or Vhite Rab­bit on twit­ter, we will do a lot more We­bXR in the fu­ture!

Writ­ten in 35 min­utes, ed­it­ed in 10 min­utes.