Define behavior when tab loses focus while presenting #15
Comments
|
From @cvan on June 1, 2016 23:7
This is a great conversation to have, but I wonder if it has a bearing on the spec. I fully anticipate there to be varying implementations of VR browser UI and window management, but they may be no more dictated by spec than the current window/tab management models that are implemented by browsers today. Is this use case categorically different from that? |
|
From @cvan on June 1, 2016 23:7
I think it is relevant to the spec, because the spec already addresses what happens to a tab that does not have focus. So I think it needs to do that more completely. And I think it's different from traditional tabs because the cost of getting it wrong is much higher - abrupt loss of tracking can literally make one sick. And specs do dictate some of that behavior, like how the If you'll bare with me, I can think of a few scenarios where a tab might lose focus without exiting presentation:
Therefore, I might propose that losing focus in the main 2d display does not interrupt VR presentation and that the security restriction about web page focus be amended so that pages that are not focused but are not presenting will still lose access to VR inputs, but once the page starts presenting, it retains access until it exits presentation. Now, this raises the question of what happens if two different web pages try to present VR at once. My first thought is that this should be impossible. If a page tries to present on the same device while another page is already doing so, either that request should fail or the previous page should be forced to exit. I'm leaning towards the latter, since we already know that a presentation request can only be made by user input. Okay, please shoot holes in my proposal, and then patch them. |
|
From @cvan on June 1, 2016 23:7
While the UX that might interrupt a VR site and the way it is animated in may be platform (Oculus Home or SteamVR) and/or Browser specific, I agree with the way @brianchirls describes the interaction with WebVR Sites. I imagine that although only one WebVR site may enter VR at a time and can only lose VR focus by exiting presentation or by user interaction (i.e. following a link), a third state may occur. In this third state, the WebVR site will get orientation and positional tracking updates, but would not receive keyboard and button presses. The VR site would effectively be focused as normal but only receive VRDisplay VRPose tracking updates as required to continue rendering the site as the user moves their head. This third state would be possible, for example, when a non-modal dialog appears as a HUD that leaves the VR site visible behind it. Input would be blocked to avoid errant interactions; however, gaze based cursors models used in the content that do not require button presses to interact may inadvertently be triggered. Browsers may avoid triggering such interactions in content while non-modal (hud) type dialogues are visible through clever designs such as attaching such hud dialogues to a motion tracked controller so the user can re-position them freely. Such non-modal (hud) dialogues should not be used for security sensitive user input, such as password entry, as the VRPose updates could be used to infer the user's interactions with things such as an on-screen keyboard. In these cases, the browser could opt to present an opaque interface and suspend all input to the WebVR site until the user is no longer interacting with the interrupting UX. WebVR content largely does not need to be aware of this behavior by the browser and platform. These are just examples of how a platform and browser may avoid issues and protect the user without affecting the WebVR API. |
|
From @cvan on June 1, 2016 23:8
I'd encourage folks with a CV1 to try this flow:
I'm ignorant about what the SDK provides - can we do something similar? |
From @cvan on June 1, 2016 23:7
Thursday Mar 17, 2016 at 15:05 GMT
Originally opened as MozillaReality/webvr-spec#20
What should happen when you switch to another tab or application while presenting in VR to an external display?
The spec says this:
...which seems to indicate a desire not to abuse the user with a jarring experience. I think it's the right call.
It also says this:
The former seems to imply that there will be some pose-tracked 3D browser UI elements, so maybe the solution is to display that in place of the formerly active tab. So would you just resume presenting the web page as soon as it regains focus? What if you're switching between two tabs that are both VR enabled?
Any ideas?
Copied from original issue: immersive-web/webxr#28
The text was updated successfully, but these errors were encountered: