Fire vrdisplayconnect on page load only if CardboardVRDisplay is used

[jsantell]

Per conversation from Twitter with Ricardo and Kip, Firefox (until 59) did not fire a vrdisplayconnect on page load if a device was connected, however other browsers did. Previously, the polyfill had a similar behavior, but would even fire on a CardboardVRDisplay if it wasn't even used (#258). This was subsequently removed (dd56464).

To achieve this functionality, we'll have to query to see if there are any native displays so we don't fire an event for a CardboardVRDisplay that won't be used (as the native VRDisplay will take priority), but @kearwood mentioned that [calling getVRDisplays could trigger UI],(https://twitter.com/kearwoodgilbert/status/951585714113671168). In the event native is not supported, this will be easy to just fire an event. But in the case where we have to query to see if any native displays exist, there's no way other than calling getVRDisplays AFAIK, other than maybe listening to vrdisplayconnect on our own, but seems like an unavoidable race condition.

Leaning towards calling getVRDisplays internally on load, and fire vrdisplayconnect for CardboardVRDisplay if no native displays exist. Currently, no browsers have a UI for calling getVRDisplays, and with WebXR spec supporting only one device at a time, and moving towards that API, this should be a good enough solution. Thoughts? @cvan @kearwood @brianchirls

[jsantell]

Noticing the following in the WebXR spec, so maybe we're in the clear to call getVRDisplays without worrying about browser UI occuring on instantiation:

Calling requestDevice() MUST NOT trigger device-selection UI as this would cause many sites to display XR-specific dialogs early in the document lifecycle without user activation.

[cvan]

Leaning towards calling getVRDisplays internally on load, and fire vrdisplayconnect for CardboardVRDisplay if no native displays exist.

From the latest WebXR Explainer:

Pages can listen to the devicechange event emitted on navigator.xr to respond to changes in device availability after the page loads. (XR devices already available when the page loads will not cause a devicechange event to be fired.)

The spec language isn't as explicit as is the Explainer text. Based on the excerpt above, I'd recommend to not fire vrdisplayconnect on load. (I believe this would break convention with WebVR v1.1 implementation and A-Frame usage, but I think that's fine to do now.)

Re: this devicechange event, I filed immersive-web/webxr#322 and commented on an old WebXR spec issue (immersive-web/webxr#184 (comment)). We'll see where the discussion goes.

As a developer, I liked the convenience of listening for an event on window, but we want to limit the API surface to be contained within the navigator.xr namespace (for clarity and eventual worker contexts).

So, navigator.xr.requestDevice() and navigator.xr.addEventListener('devicechange', …) should suffice, I think.

[jsantell]

The spec language isn't as explicit as is the Explainer text. Based on the excerpt above, I'd recommend to not fire vrdisplayconnect on load. (I believe this would break convention with WebVR v1.1 implementation and A-Frame usage, but I think that's fine to do now.)

This is just for the 1.1 spec, though -- and with Firefox 59 now firing vrdisplayconnect on load, all browsers will fire this event if there's access to a VRDisplay, shouldn't the polyfill attempt to mimic that behavior?

Good call on the WebXR issue filing!

[cvan]

yeah, I thought about that. it’s probably best to be 1.1 compliant and not worry about the WebXR changes yet since there are no shipped implementations.

so, 👍 to your proposal to fire the event, yes.