New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 845283 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: 10
NextAction: ----
OS: ----
Pri: 1
Type: Task

Blocking:
issue 845702



Sign in to add a comment

WebXR: Decide on and clearly implement focus requirements

Project Member Reported by ddorwin@chromium.org, May 21 2018

Issue description

There are currently four possible session types:
1. Non-exclusive VR ("magic window")
2. Exclusive VR ("presentation")
3. Non-exclusive AR
4. Exclusive AR

There are multiple capabilities that may have different requirements. These include:
A. Getting poses
  - This can be further broken down into full and reduced frequency.
B. Submitting frames
C. Input?
D. Requesting a hit-test ( issue 833633 ) or other real world information

In addition, there are multiple types of focus:
I. Frame (i.e. iframe)
II. Tab
III. Window
IV. Device (headset)
V. Runtime/OS?
VI. Cross-origin vs. same-origin to the focused Frame

We need to determine the appropriate requirements for each session and operation combination then implement those in a way that is clearly understandable and in a central location. Determining the requirements may involve spec work, but we can at least develop our recommendations and start by implementing those.

Currently, most of our focus checks are in Blink. We may want more checks in the browser process for added security. Currently, the only such check is in VRDisplayImpl::RequestPresent(). Defining focus at a higher level will also help (or provide a model for) when to pause ARCore ( issue 838513 ).
 
Specifically, consider adding checks to VRDisplayImpl::GetPose() and VRDisplayImpl::GetFrameData().

If we wanted to add focus checks for presentation/exclusive sessions, we'd to add those in the implementations of VRPresentationProvider::GetVSync().
We should also consider sending blur/focus events on the session when the page loses/gains focus.

This would allow developers that care when rendering/access to the device is 'paused' to implement that in a consistent way instead of having to listen to both window blur and device blur.

There's also the question of do we send device blur/focus events to the session when it doesn't have frame focus. We currently would, which would potentially allow backgrounded pages to record things like when the user takes their headset off. (This problem goes away if we blur when losing frame focus, as we won't re-blur if the headset is taken off or something)
Labels: XR-Device
Blocking: 845702
Labels: XR-Spec
Components: Blink>WebXR
Labels: BlinkWebXR
Removing Blink>WebVR component and assigning to Blink>WebXR 
Labels: -BlinkWebXR
Removing Blink>WebVR component and assigning to Blink>WebXR 
Components: -Blink>WebVR
EstimatedDays: 10
Added estimate 10d:
mthiessen@ says 5d engineering effort (3 impl + 2 test)
lincolnfrog@ estimates 5d spec work - write design doc, file issue, gather feedback, etc. Not calendar days but total days of work to figure out spec.
Labels: -M-69 M-71
Labels: AR-Rendering
Labels: -Proj-XR-AR -M-71 -AR-Rendering Proj-XR
Relevant spec issue: https://github.com/immersive-web/privacy-and-security/issues/9. This should result in a change to WebXR Device API that we would implement.

Sign in to add a comment