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

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: ----
Proj-XR

Blocking:
issue 719079


Show other hotlists

Hotlists containing this issue:
VR-Automated-Tests


Sign in to add a comment
link

Issue 710863: WebVR in IFRAME broken in Chrome 58 Beta on Android, regression from 57 Stable

Reported by jesm...@kaon.com, Apr 12 2017

Issue description

Device name: Axon ZTE A2017U_2316

From "Settings > About Chrome"
Application version: Chrome Beta 58.0.3029.54
Operating system: Android 7.1.1;ZTE A2017U Build/NMF26F

URLs (if applicable): https://www.kaon.com/3D-product-models

Steps to reproduce:
(1) Enable webvr if necessary (there's an origin trial, but it's about to expire)
(2) Tap the picture of the router at the top of the screen
(3) Tap the goggles icon at the top of the screen

Expected result:

WebVR in Daydream should work correctly.

Actual result:

WebVR doesn't work.
This is a regression: The exact page works great in Chrome 57 Stable.
The 3D content is inside an IFRAME, and you'll notice that the fullscreen button does work correctly. (The IFRAME has allowfullscreen set, which I believe implies allowvr, right?)
Also, if you visit the IFRAME'd page directly, that works fine in WebVR:
https://www.kaon.com/catalog/tours/product.html#nexus;nohelp;:
So it appears the issue is being caused by the IFRAME.
I tried some trivial IFRAME cases, like embedding the WebVR.info stuff, and that works.
As near as we can tell, we just aren't being called to render frames.
 

Comment 1 by candr...@chromium.org, Apr 12 2017

Components: Blink>WebVR

Comment 2 by mthiesse@chromium.org, Apr 12 2017

Cc: klausw@chromium.org

Comment 3 by klausw@chromium.org, Apr 12 2017

Cc: bajones@chromium.org
FWIW, I tested the direct link briefly on Chrome Canary 59 and got Javascript errors due to using WebVR methods that were recently removed from the implementation:

LeptonVRImageSensor reset created 0,0.9333333333333333 1,1
lepton_webgl_obf.js:1 Uncaught (in promise) TypeError: vrDisplay.resetPose is not a function
    at LeptonView.Lepton.LeptonView.reset (lepton_webgl_obf.js:1)
    at lepton_webgl_obf.js:1
    at <anonymous>

I patched in a no-op VRDisplay.prototype.ResetPose, then ran into the next issue that VRFieldOfView also no longer exists.

Comment 4 by jesm...@kaon.com, Apr 13 2017

We'll take a look at that API use, and I'll update this thread when we've got a workaround in place.

On the desktop, we've been using the Chromium experimental build, not Canary. The code on that page works in the Chromium experimental from 2/17/17, and in Chromium Android 57 Stable & 58 Beta. It works directly on all three, and in the IFRAME on everything except 58 Beta.

Comment 5 by klausw@chromium.org, Apr 13 2017

Can you please try M59 canary too?

Comment 6 by jesm...@kaon.com, Apr 13 2017

Where are the docs for the new WebVR API in M59? We can't find them. If VRFieldOfView was removed, what was it replaced with?

Comment 7 by klausw@chromium.org, Apr 13 2017

bajones@ is working on a docs update. The new approach is to use the
projection matrices supplied in VRFrameData as-is for rendering. If you
need the FOV separately, i.e. for culling geometry, you'd need to calculate
it from the projection matrix. That's basically the reverse calculation for
building a projection matrix, see for example
http://answers.unity3d.com/questions/770838/how-can-i-extract-the-fov-information-from-the-pro.html

Comment 8 by ddorwin@chromium.org, Apr 17 2017

Cc: meganlindsay@chromium.org
Labels: Proj-VR M-58

Comment 9 by klausw@chromium.org, Apr 17 2017

Quick update - one issue seems to be that the iframe isn't focused after entering presentation, and this is pausing vrDisplay.requestAnimationFrame processing. I'm not sure what's going on here, but as a workaround can you try calling .focus() on the iframe element manually? I'm still looking into what's going on here.

Comment 10 by jesm...@kaon.com, Apr 18 2017

Yup, calling focus on the IFRAME after it's added to the DOM fixes the issue.
Also, calling window.focus() from inside the IFRAME when the user touches the VR button fixes the issue. (This is preferable, since I can change it in one place instead of on dozens of web sites where our content gets embedded.)
I tested those cases on my staging server. I'll hold off putting them into production so you can continue to investigate.

Comment 11 by ddorwin@chromium.org, Apr 18 2017

Labels: -M-58 M-60

Comment 12 by ddorwin@chromium.org, Apr 28 2017

Owner: klausw@chromium.org
Status: Started (was: Unconfirmed)

Comment 13 by bugdroid1@chromium.org, Apr 28 2017

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/984c8d18acf4b891d5bf39db6a898e2187340e0f

commit 984c8d18acf4b891d5bf39db6a898e2187340e0f
Author: klausw <klausw@chromium.org>
Date: Fri Apr 28 21:42:29 2017

WebVR: fix focus while presenting

If the WebVR document loses focus, check if the new focused element is an
embedding local parent frame. If that's the case, continue presenting.  This
fixes issues with Cardboard-style touch events that are reported as a click at
viewport (0, 0) where the resulting focus loss stopped presentation.

BUG= 710863 

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

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

Comment 14 by bugdroid1@chromium.org, May 1 2017

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

commit b85de8ac470aef12f8d666b881cd9888a8b2e645
Author: mthiesse <mthiesse@chromium.org>
Date: Mon May 01 17:40:30 2017

Revert of WebVR: fix focus while presenting (patchset #1 id:1 of https://codereview.chromium.org/2847233002/ )

Reason for revert:
So there are a bunch of problems with this CL.

1. Now third-party iframes can just arbitrarily read head pose without needing focus as long as the main page has focus.

2. We've just broken the assumption that only one VrDisplay can be focused at a time. If the page has two iframes that want poses, and one presents, they're now both going to be fighting with each other to get the pose information.

Original issue's description:
> WebVR: fix focus while presenting
>
> If the WebVR document loses focus, check if the new focused element is an
> embedding local parent frame. If that's the case, continue presenting.  This
> fixes issues with Cardboard-style touch events that are reported as a click at
> viewport (0, 0) where the resulting focus loss stopped presentation.
>
> BUG= 710863 
>
> Review-Url: https://codereview.chromium.org/2847233002
> Cr-Commit-Position: refs/heads/master@{#468140}
> Committed: https://chromium.googlesource.com/chromium/src/+/984c8d18acf4b891d5bf39db6a898e2187340e0f

TBR=bajones@chromium.org,klausw@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 710863 

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

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

Comment 15 by bugdroid1@chromium.org, May 5 2017

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/89079d08e53122fc1921517942e259ec1e674d2d

commit 89079d08e53122fc1921517942e259ec1e674d2d
Author: mthiesse <mthiesse@chromium.org>
Date: Fri May 05 23:40:00 2017

WebVR: lock focus while presenting to presenting window

This CL is kept intentionally simple for merging back to M59 to fix the regression, but hides some complexity.

This won't violate the assumption of one VRDisplay having a VSync provider at a time because VrDisplayImpl::GetVRVSyncProvider drops requests from displays that aren't presenting while presentation is active.

However, if a non-presenting VrDisplay actually gets focus while a different VrDisplay is presenting (possibly from directing the controller click to a different display) then that non-presenting VrDisplay will fail to get a VSync provider even after presentation ends because its focused state won't change and the original request will have failed. This means that a page with multiple VrDisplays will under certain degenerate cases fail to resume magic window mode after presenting until the focus changes again.

BUG= 710863 

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

[modify] https://crrev.com/89079d08e53122fc1921517942e259ec1e674d2d/chrome/android/javatests/src/org/chromium/chrome/browser/vr_shell/VrTestBase.java
[modify] https://crrev.com/89079d08e53122fc1921517942e259ec1e674d2d/chrome/android/javatests/src/org/chromium/chrome/browser/vr_shell/WebVrTest.java
[add] https://crrev.com/89079d08e53122fc1921517942e259ec1e674d2d/chrome/test/data/android/webvr_instrumentation/html/test_presentation_locks_focus.html
[modify] https://crrev.com/89079d08e53122fc1921517942e259ec1e674d2d/chrome/test/data/android/webvr_instrumentation/resources/webvr_boilerplate.js
[modify] https://crrev.com/89079d08e53122fc1921517942e259ec1e674d2d/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/89079d08e53122fc1921517942e259ec1e674d2d/third_party/WebKit/Source/modules/vr/VRDisplay.h

Comment 16 by mthiesse@chromium.org, May 8 2017

Blocking: 719079

Comment 17 by mthiesse@chromium.org, May 8 2017

Labels: -M-60 Merge-Request-59 M-59

Comment 18 by sheriffbot@chromium.org, May 8 2017

Project Member
Labels: -Merge-Request-59 Merge-Review-59 Hotlist-Merge-Review
This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 19 by mthiesse@chromium.org, May 8 2017

Note that only commit 89079d08e53122fc1921517942e259ec1e674d2d will be merged back.

Comment 20 by ddorwin@chromium.org, May 15 2017

I verified that with this patch in a custom M59 Beta build from mthiesse, the failure to enter issue in  issue 719079  does not repro.

Comment 21 by amineer@chromium.org, May 15 2017

My guess is that Pri-3 isn't appropriate here - merge approved for M59 branch 3071 but in the future try to tag stuff appropriately as that will get you punted in the future.

Comment 22 by amineer@chromium.org, May 15 2017

Labels: -Merge-Review-59 Merge-Approved-59

Comment 23 by mthiesse@chromium.org, May 15 2017

Labels: -Pri-3 Pri-1

Comment 24 by bugdroid1@chromium.org, May 15 2017

Project Member
Labels: -merge-approved-59 merge-merged-3071
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cb20474507616ce33723dfb02723e952703f3d88

commit cb20474507616ce33723dfb02723e952703f3d88
Author: Michael Thiessen <mthiesse@google.com>
Date: Mon May 15 18:54:11 2017

WebVR: lock focus while presenting to presenting window

This CL is kept intentionally simple for merging back to M59 to fix the regression, but hides some complexity.

This won't violate the assumption of one VRDisplay having a VSync provider at a time because VrDisplayImpl::GetVRVSyncProvider drops requests from displays that aren't presenting while presentation is active.

However, if a non-presenting VrDisplay actually gets focus while a different VrDisplay is presenting (possibly from directing the controller click to a different display) then that non-presenting VrDisplay will fail to get a VSync provider even after presentation ends because its focused state won't change and the original request will have failed. This means that a page with multiple VrDisplays will under certain degenerate cases fail to resume magic window mode after presenting until the focus changes again.

BUG= 710863 

Review-Url: https://codereview.chromium.org/2859533003
Cr-Original-Commit-Position: refs/heads/master@{#469804}
Review-Url: https://codereview.chromium.org/2881233002 .
Cr-Commit-Position: refs/branch-heads/3071@{#560}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/cb20474507616ce33723dfb02723e952703f3d88/chrome/android/javatests/src/org/chromium/chrome/browser/vr_shell/WebVrTest.java
[add] https://crrev.com/cb20474507616ce33723dfb02723e952703f3d88/chrome/test/data/android/webvr_instrumentation/html/test_presentation_locks_focus.html
[modify] https://crrev.com/cb20474507616ce33723dfb02723e952703f3d88/chrome/test/data/android/webvr_instrumentation/resources/webvr_boilerplate.js
[modify] https://crrev.com/cb20474507616ce33723dfb02723e952703f3d88/third_party/WebKit/Source/modules/vr/VRDisplay.cpp
[modify] https://crrev.com/cb20474507616ce33723dfb02723e952703f3d88/third_party/WebKit/Source/modules/vr/VRDisplay.h

Comment 25 by mthiesse@chromium.org, May 15 2017

Status: Fixed (was: Started)

Comment 26 by btebbs@chromium.org, Jul 4 2018

Components: Blink>WebXR

Sign in to add a comment