Clarify "VR is supported" in vrEnabled definition

[ddorwin]

https://w3c.github.io/webvr/#navigator-vrenabled-attribute says vrEnabled is true " if the context object is allowed to use the feature indicated by attribute name allowvr and VR is supported," but there is no definition of what it means for VR to be supported.

Doesn't the availability of the APIs defined in this specification mean that VR is supported (since an HMD is not required)? I suppose it is possible that a UA would expose these APIs but not support even a non-presenting (i.e. "magic window") display, but does this attribute need to track that?

More broadly, what is the use case for this attribute? Is it to allow an app to quickly determine that it should not display UI for presenting? If so, it probably makes sense to have return false if there are zero displays that can present. If not, why is this attribute necessary rather than just getting a rejected promise from getVRDisplays()?

For reference, the referenced text was added in f8d15c6 when the attribute was added and moved to its current location in bc68bf4.

[cvan]

I agree, totally, that this is unclear. @toji @kearwood @mkeblx, thoughts?

Thanks for filing!

[DigiTec]

I would also like to make sure that we reserve the right for the UA to allow a dynamic toggle to make this attribute true/false. While we have done a ton of work in the platform to not present that VR is supported unless we have some high confidence that it might be, a user may wish to go into a "don't offer me any VR" mode especially with a mobile device when they are nowhere near their head mount.

Would we give too much away by having a vrCapable and vrEnabled pair of flags? Thinking through use cases here on, user is mobile, author wants to offer them VR in the future (vrCapable && !vrEnabled) vs user is ready for VR and author wants to go into VR (vrEnabled, implying also that vrCapable is true)

[toji]

vrEnabled is no longer part of the current spec. If/when we add similar functionality back in it'll probably be in the form of Feature Policy (See Issue #86). Closing.