vrdisplayconnect event fires on unused shim VRDisplay

[brianchirls]

The event fires on a shim CardboardVRDisplay as soon as it's created, even though it may not be used. After the display is created, we may detect a natively implemented Cardboard (or other) device. If that happens, the shim display will not be included in the list of displays returned by getVRDisplays.

I propose the following:

• Hold off on creating the shim Cardboard display until the getVRDisplays promise is resolved and either there are no other displays or ALWAYS_APPEND_POLYFILL_DISPLAY is true.
• If a native device is found later (either by firing vrdisplayconnect or from getVRDisplays, disconnect the shim Cardboard, fire vrdisplaydisconnect and set any state accordingly (unless it's presenting!)
• If the native display goes away, restore the shim Cardboard display and fire vrdisplayconnect

Related to: #40, #244, #255

[cvan]

FWIW, the experimental Chromium WebVR builds (and Firefox used to/should/will) fire vrdisplayconnect only when a display is reconnected after disconnecting.

I propose the following:

• Hold off on creating the shim Cardboard display until the getVRDisplays promise is resolved and either there are no other displays or ALWAYS_APPEND_POLYFILL_DISPLAY is true.

So, if we're going to follow the behaviour spec'd in the WebVR API v1.1, we should not fire it even after getVRDisplays resolves.

• If a native device is found later (either by firing vrdisplayconnect or from getVRDisplays, disconnect the shim Cardboard, fire vrdisplaydisconnect and set any state accordingly (unless it's presenting!)
• If the native display goes away, restore the shim Cardboard display and fire vrdisplayconnect

When you say "native device," what are the scenarios in which you'd expect this to happen? If a native device is found, then the native WebVR API (i.e., navigator.getVRDisplays) would already exist, and the webvr-polyfill would not be initialised. Am I missing some scenario?

It's a little tricky in the Cardboard case because the phone itself is the headset. So, the VR Display can't technically ever be "disconnected." If the active window loses focus, or the user switches to another app on the phone, I could see it being useful to fire an event. But that event wouldn't make sense to be vrdisplaydisconnect event. Nor, IMO, would it make sense to fire a vrdisplaydeactivate event. But, it would make sense to fire a vrdisplayblur when the active VR tab loses focus/visibility (i.e., when window's blur or visibilitychange when document.hidden is true); and, expectedly, vrdisplayfocus would be fired when the VR tab regains focus.

@brianchirls, @klausw, @jsantell: Thoughts?

[brianchirls]

First, regarding whether vrdisplayconnect should fire immediately, the spec says the browser "MAY" fire the event but doesn't seem to specify any further details. I'd be okay with leaving it out here, except that it would be useful for #255. (I just noticed your comment there, so I'll get to that next.) But it should definitely not fire if the cardboard display is not made available, whether because it's not compatible or because there's a native device supplied.

As for native display devices found later, I'm mostly thinking we should prepare for unknown devices and circumstances. That's kinda the whole point of using the web. But more specifically, @klausw told me that Google VR Services will provide either a Cardboard display or Daydream, depending on which devices the user has selected in the global settings. And there won't be any display provided if Google VR Services are not installed. I don't know what the browser does if you install the service or change the setting while the page is loaded. But we should be prepared to handle it gracefully and allow for changes in the browser's behavior in the future as well as different behaviors from other browsers/devices that may show up later.

[cvan]

@klausw: can you provide an update here of expected behaviour?