Detect WebVR Support with JavaScript
It's been two years since I was heavily involved with WebVR at Mozilla but, despite not contributing every day, I can see VR making leaps and bounds, from Firefox making an increased effort to Chrome pushing VR and Oculus and HTC (Vive) improving their offerings. Native games are getting better but, more importantly, browsers are getting faster and three.js and aframe are empowering incredible VR experiences with JavaScript.
Before you can serve up VR experiences, however, you need to ensure the browser supports VR experiences. To do so, you need to ensure navigator.getVRDisplays is available:
const supportsVR = 'getVRDisplays' in navigator;
if (supportsVR) {
navigator.getVRDisplays().then(function(displays) {
// ... Load VR experience
});
}
else {
// ... Show "you need {x} browser" message
}
If navigator.getVRDisplays is present, it's likely that the browser supports VR and AR experiences.
Virtual reality and augmented reality have the potential to change the world and enrich lives. Learning how to code VR experiences will get you ahead of the curve, and as always, coding those experiences for the browser will break down the barrier of entry!
![JavaScript Promise API]()
While synchronous code is easier to follow and debug, async is generally better for performance and flexibility. Why "hold up the show" when you can trigger numerous requests at once and then handle them when each is ready? Promises are becoming a big part of the JavaScript world...
![Designing for Simplicity]()
Before we get started, it's worth me spending a brief moment introducing myself to you. My name is Mark (or @integralist if Twitter happens to be your communication tool of choice) and I currently work for BBC News in London England as a principal engineer/tech...
![MooTools Kwicks Plugin]()
I wrote a post titled Get Slick with MooTools Kwicks ages ago. The post was quite popular and the effect has been used often. Looking back now, the original code doesn't look as clean as it could. I've revised the original...
![Page Visibility API]()
One event that's always been lacking within the document is a signal for when the user is looking at a given tab, or another tab. When does the user switch off our site to look at something else? When do they come back?
Looks like
is deprecated and should not be used any more. Oculus Quest 2 does not implement it, so it can’t really be relied on: https://discourse.threejs.org/t/navigator-getvrdisplays-not-working-on-oculus-quest-browser/23273