New issue
Advanced search Search tips

Issue 680209 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Feb 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug
Proj-XR



Sign in to add a comment

WebVR does not properly stop presenting if requestPresent rejects

Project Member Reported by bsheedy@chromium.org, Jan 11 2017

Issue description

Reproducible in Android Canary 57.0.2978.0 on a Pixel
Reproduction steps:
1. Access https://webvr.info/samples/03-vr-presentation.html on the Android device
2. Connect the device to a workstation and inspect the tab (F12 -> Remote devices)
3. Run the following Javascript in the console:

var disp; var can = document.getElementById("webgl-canvas");
navigator.getVRDisplays().then( (displays) => {disp = displays[0];});
disp.requestPresent([{ source: can}]);
<< Complete DON flow >>
disp.requestPresent([{ source: can, leftBounds: [0, 1]}]);

Actual outcome: The page goes back to magic window, except that the VR overlay is still present. Pressing back goes to the previous page. Pressing the X on the VR overlay removes the overlay.
Expected outcome: The page goes back to magic window, exactly as if the user had manually exited VR (no overlay).
 
Labels: Proj-VR
Description: Show this description
Cc: bajones@chromium.org
Should the second requestPresent() instead be rejected but leave the existing presentation active?
No. According to the spec, presentation should immediately stop if requestPresent() rejects.

In this case, VRDisplay thinks that it's no longer presenting, but the overlay is not being removed.

Comment 5 by sko...@chromium.org, Jan 12 2017

Labels: -Pri-1 Pri-2
Status: Available (was: Untriaged)
Doesn't seem like a P1 since the app is behaving in an incorrect manner, but still should be fixed.
bajones explained that it is reasonable for an application to requestPresent() multiple times. A rejection means that what the application was trying to present is not being presented, so there isn't really anything to continue displaying.

Still, this is an exceptional case, so P2 seems appropriate.
Labels: -M-57
Owner: maksim.s...@intel.com
Status: Assigned (was: Available)
I would like to work on this issues if nobody has taken it yet.
Assigning to myself.

Comment 9 by hokein...@gmail.com, Feb 13 2017

Cc: shaobo....@intel.com
@shaobo is currently working on this issue, a potential fixing patch: https://codereview.chromium.org/2689563008/.
Owner: ----
removing myself then
Project Member

Comment 11 by bugdroid1@chromium.org, Feb 20 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a8725caafe812944aa590f27e8711eab810bf1a1

commit a8725caafe812944aa590f27e8711eab810bf1a1
Author: shaobo.yan <shaobo.yan@intel.com>
Date: Mon Feb 20 02:22:17 2017

Fix WebVR does not properly stop presenting if requestPresent rejects.

Directly call forceExitPresent won't stop
presenting correctly.

BUG= 680209 

Review-Url: https://codereview.chromium.org/2689563008
Cr-Commit-Position: refs/heads/master@{#451544}

[modify] https://crrev.com/a8725caafe812944aa590f27e8711eab810bf1a1/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/a8725caafe812944aa590f27e8711eab810bf1a1/third_party/WebKit/Source/modules/vr/VRDisplay.h

Status: Fixed (was: Assigned)
The fix appears to work on ToT, as calling requestPresent([{source: null}]) while presenting ends presentation. I'll go ahead and close this.
Do we have a test?
Yes and no - there's a layout test that covers this scenario, but since this particular bug was purely visual (the display was no longer presenting according to WebVR), it wasn't caught. I've filed  Issue 695514  to track adding a test for this particular bug.
Components: Blink>WebXR

Sign in to add a comment