Introduce navigator.xr.getAvailability method

[cvan]

I'm aware that in existing Chromium/Firefox implementations, WebVR intent was gated on navigator.getVRDisplays (e.g., VR controllers won't be enumerated when called navigator.getGamepads() unless there was a prior call to navigator.getVRDisplays). Implementations of the Gamepad API have similar heuristics:

If there exists a listener for a gamepadconnected event, or there is a call to navigator.getGampads(), then the Gamepad code path is engaged in the browser.

---

navigator.vr.getAvailability() should follow an algorithm that resolves a Promise<boolean>, with the boolean indicating whether the UA supports (or allows) VR in the current browsing context/document (i.e., not simply whether a VR device has been found).

Developers could listen to an event availabilitychange fired on navigator.vr. This would also respect the Feature-Policy (<iframe enable="vr">), which is described in detail in issue #25.

I researched Web Bluetooth, WebUSB, Presentation API, Web Audio, Web MIDI, among others, and found them to support similar methods:

• https://webbluetoothcg.github.io/web-bluetooth/#availability
• Improve the getAvailability() design WebBluetoothCG/web-bluetooth#307 (comment)
• https://w3c.github.io/presentation-api/#dom-presentationrequest-getavailability
• https://github.com/w3c/webvr/pull/116/files#r98351045

I want to remind that the Permissions API is likely a good candidate to adopt if it's decided that we ought to gate VR access to explicit user permission. For now, let's leave that off the table.

[RafaelCintron]

The availability of the API has to do with whether a) it is allowed from a policy standpoint and b) whether there are VR displays plugged in. Unless I am missing something, A should be able to be determined synchronously. Since we already have getVRDisplays and the connected event for B, why can't availability be exposed as a synchronous attribute instead of be promised based?

The FullScreen feature, which you did not mention, has availability as the fullscreenenabled attribute.

[cvan]

Since we already have getVRDisplays and the connected event for B, why can't availability be exposed as a synchronous attribute instead of be promised based.

I haven't looked at the Chromium and Firefox sources for the WebVR management, but IIRC we engage VR mode when a call is made to navigator.getVRDisplays. Seeing as developers will (and should) listen to the events fired on navigator.vr (i.e., displayconnect, displaydisconnect, and navigate), what is going to be the signal of user intent to want to use VR?

I may be misunderstanding how we're deriving intent (and ability) to use VR. What's to prevent unnecessary polling when a VR headset not be plugged in (despite the HMDs' SDKs being present on the machine) or the majority of sites (for the time being) a user access won't be WebVR-capable?

For what it's worth, other APIs seem to handle this by gating permissions to powerful APIs with the Permissions API, with calls to navigator.permissions.query. I know we don't want to introduce (at least not now) a dependency for the Permissions API.

This could be a synchronous property (note that @toji did add navigator.vr.getAvailability as a Promise-based method in his last PR, #116). In either case, I'd recommend also adding an availabilitychange event that gets fired on navigator.vr. I think it's quite likely that some UAs will want to disallow presentation to bad actors (e.g., sites indexed in the Safe Browsing API) and just based on user action (à la UA's pop-up blockers and the Permissions API prompts/options).

Related to this: there's issue #86 on file for handling <iframe>s with the proposed Feature Policy.

[RafaelCintron]

I agree that starting the VR machinery is something user agents should postpone as late as possible. Up to this point, I've been considering the act of hooking the displayconnect/displaydisconnect events and/or calling getVRDisplays as the signal to do this startup.

If we do not want to tackle permissions APIs, what does getAvailability buy us that we don't already have with the existing mechanisms?

[kearwood]

Hello! The Firefox implementation already behaves as you describe. It avoids activating any VR hardware until either the events are hooked or getVRDisplays is called. I would be in support of defining this behaviour in the spec, but open to hear of advantage to making this more explicit. Cheers, Kearwood "Kip" Gilbert

…

Sent from my iPad

On Feb 8, 2017, at 6:04 PM, Rafael Cintron ***@***.***> wrote: I agree that starting the VR machinery is something user agents should postpone as late as possible. Up to this point, I've been considering the act of hooking the displayconnect/displaydisconnect events and/or calling getVRDisplays as the signal to do this startup. If we do not want to tackle permissions APIs, what does getAvailability buy us that we don't already have with the existing mechanisms? ― You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ddorwin]

I think Feature Policy could be handled by making navigator.vr undefined.
/cc @raymeskhoury who can provide more context about Feature Policy.

Other than that, what specific use cases would we need to decide the availability of the WebVR API? getDisplays() seems sufficient for indicating we need to spin up the device APIs. (Regardless of the mechanism, sites and libraries will need to use this API only when they actually intend to use VR.)

The Web Bluetooth and Presentation API uses seem slightly different - the former is querying Bluetooth support (there is no getDevices()) and the latter accepts a request object for which it checks specific display availability.

[jonathanKingston]

I know we don't want to introduce (at least not now) a dependency for the Permissions API.

Is there a reason for the dependency issue? Is there harm in using the permission API and auto granting the permission, so that in future the UA can decide if they want to behave differently. Especially as this would also give the event for change out of the box.

[cvan]

Yes, the UA could automatically set the state as "granted": https://w3c.github.io/permissions/#dom-permissionstate-granted

👍 from me on that

[cvan]

@toji: @NellWaliczek: Ought we to remove this in favour of navigator.xr.requestDevice(…)?

[cvan]

Is there still a need for a navigator.xr.getAvailability(…) method now that we have navigator.xr.requestDevice(…) and navigator.xr.addEventListener('devicechange', …)?

On a related note: I filed a new issue to define the behaviour and improve documentation of the devicechange event: #322

If folks agree, we can keep the discussion to #322 and close this issue. Let me know. Thanks!

[toji]

Closing to take the suggestion to keep the discussion in #322