immersive-web
Establish expectations regarding app-initiated browser UI while presenting
From @ddorwin on November 9, 2017 2:10
On desktop, WebVR presentation results in two separate and isolated displays for a single app. Since the same app is driving both displays, any API call (other than those on VRDevice and related objects) could be related to activity on either or both displays (or from either form of input). This is fine except for UI that is initiated but not controlled by the app. Examples include permission prompts and UI for the Payment Request API.
In order to enable developers to create experiences that are predictable across implementations, we should probably establish expectations for where such UI is displayed. Although UI is often out of scope for web specs, this seems like a necessary exception.
As for what that expectation should be, it would seem that such UI should at least be displayed to the presenting VR display. Perhaps implementations should be allowed to optionally display to the traditional display too. This may be useful for multi-user or "demo" scenarios.
We may also want to provide guidance for implementations that cannot display such UI to the presenting VR display. For example, to reject with or throw INVALID_STATE_ERR.
On a related note, we may also want to recommend in the security/privacy considerations section that indicators, such as for microphone use and other privacy-sensitive features, be displayed in both places.
Copied from original issue: immersive-web/webxr#299
Totally agree that this is a topic we should dig into!
Somewhat relatedly, in the WebVR 1.1 design we have the VRDisplayPointerRestricted and VRDisplayPointerUnrestricted events that roughly equate to whether or not there is someone actively engaging with that desktop display. Perhaps similar events would be useful to developers (though renamed) in WebVR 2.0?
From @kearwood on January 16, 2018 23:16
+1 for this. For Firefox UI, we do-not-yet, but intend-to-soon present all prompts within the XR display that is displaying the content. In some contexts, it will make sense to display UI mirrored on both displays, but in other cases as Nell points out, we may only want it visible within the presenting XR display. It would be useful for content to know that the browser is requesting interaction and on which display. We need to be careful if this exposes too much information to content; however, so should explore how it could be used maliciously.
When we obscure the content to present some UI, we would fire focus and blur events. Perhaps this is something that should be consistent as well.
From @ddorwin on January 17, 2018 1:29
Related to exposing too much information, implementations should ensure, for example, that behaviors that can result in focus and blur events are consistent between normal and private browsing modes among other things.
While I'm (edit: not) convinced it should be in the spec, I think we should discuss UI guidelines for an immersive permissions prompt (beyond where the prompt is located).
I've been playing around with the Oculus Go and something I noticed was that during the permission prompt, I was floating in space. It was disorienting and I wanted to complete the permission prompt ASAP. IMO there needs to be a certain amount of 'comfort' (for lack of a better term) for any security/privacy-related prompt so that users don't immediately click through.
I'm inclined to agree. The last thing we need is encouraging users clicking through like they do with invalid x.509 certs. There needs to be a mechanism not just to allow users to see it comfortably, but also in a way that they understand what they are being asked to expose.
