WebVR in IFRAME broken in Chrome 58 Beta on Android, regression from 57 Stable
Reported by
jesm...@kaon.com,
Apr 12 2017
|
||||||||||||||
Issue descriptionDevice 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.
,
Apr 12 2017
,
Apr 12 2017
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.
,
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.
,
Apr 13 2017
Can you please try M59 canary too?
,
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?
,
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
,
Apr 17 2017
,
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.
,
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.
,
Apr 18 2017
,
Apr 28 2017
,
Apr 28 2017
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
,
May 1 2017
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
,
May 5 2017
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
,
May 8 2017
,
May 8 2017
,
May 8 2017
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
,
May 8 2017
Note that only commit 89079d08e53122fc1921517942e259ec1e674d2d will be merged back.
,
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.
,
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.
,
May 15 2017
,
May 15 2017
,
May 15 2017
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
,
May 15 2017
,
Jul 4
|
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by candr...@chromium.org
, Apr 12 2017