I understand this is the expected behaviour. 

I think there's a bit of confusion around what defines a VRDisplay right now. A VRDisplay used to be any screen that could show content, and thus a mobile+cardboard would be a valid VRDisplay. It seems now that a VRDisplay implies more features, like lens distortion.

So canary+webvr in a regular phone has webvr support, but no displays. And canary+webvr in a daydream phone has a daydream display (which can be used with a daydream view or a cardboard). I think this is the case, which means: if there are displays, you can use any; if there aren't, abort or use your own distortion.

If this is the case, the big question is how's it going to be when webvr support is officially released for chrome android.

This is indeed expected behavior for now.

The first thing to recognize is that the WebVR API may return an empty array at any time, even when you might think it should be guaranteed to get a VRDisplay back. Maybe the browser has a setting that lets users block certain pages or a whole session from using VR? Maybe your drivers are out of date? Maybe another app has been grated exclusive access to the device? Point is, there's no shortage of reasons why you may not get a VRDisplay back. Your page should be designed to handle it gracefully.

Secondly, in this case the intent is that you WILL eventually get VRDisplays back for Cardboard-style use almost all the time, but that's not implemented yet. (It's dependent on the Google VR service being deployed more widely.) So at this point it only works with Daydream ready devices, though you can use said devices with a Cardboard headset. This is a temporary issue, and should be resolved in the near-ish future.

Closing as WAI, with my apologies for the confusion.

Thanks for the clarification - I was aware that it is always possible to
resolve with an empty array, but it surprised me as the phone certainly
should've shown up as a Cardboard device.

Thank you very much for the quick response, I think this clarification is
very useful indeed!

Cheers!

2016-12-11 21:22 GMT+01:00 bajo… via monorail <
monorail+v2.1572007341@chromium.org>: