VR deep link tests hitting asserts |
|||||||
Issue descriptionWebVrTransitionTest#testTrustedIntentAllowsAutoPresent and WebVrInputTest#testAppButtonNoopsWhenDeepLinked are both failing due to hitting an assert in VrShellDelegate.removeBlackOverlayView. https://chromium.googlesource.com/chromium/src/+/6be04e3c32f75b0b8f151ebc9b07ce9c69e45dbd is the CL that caused this to start happening, but it's likely that it just exposed an existing issue that was hidden until now. Example stack trace: java.lang.AssertionError at org.chromium.chrome.browser.vr_shell.VrShellDelegate.removeBlackOverlayView(VrShellDelegate.java:960) at org.chromium.chrome.browser.vr_shell.VrShellDelegate.enterVr(VrShellDelegate.java:922) at org.chromium.chrome.browser.vr_shell.VrShellDelegate.enterVrAfterDon(VrShellDelegate.java:868) at org.chromium.chrome.browser.vr_shell.VrShellDelegate.handleDonFlowSuccess(VrShellDelegate.java:1393) at org.chromium.chrome.browser.vr_shell.VrShellDelegate.onResume(VrShellDelegate.java:1366) at org.chromium.chrome.browser.vr_shell.TestVrShellDelegate.onResume(TestVrShellDelegate.java:113) at org.chromium.chrome.browser.vr_shell.VrShellDelegate.onActivityStateChange(VrShellDelegate.java:748) at org.chromium.base.ApplicationStatus.onStateChange(ApplicationStatus.java:351) at org.chromium.base.ApplicationStatus.access$200(ApplicationStatus.java:35) at org.chromium.base.ApplicationStatus$2.onActivityResumed(ApplicationStatus.java:262) at android.app.Application.dispatchActivityResumed(Application.java:216) at android.app.Activity.onResume(Activity.java:1251) at android.support.v4.app.FragmentActivity.onResume(FragmentActivity.java:458) at org.chromium.chrome.browser.init.AsyncInitializationActivity.onResume(AsyncInitializationActivity.java:446) at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1269) at android.support.test.runner.MonitoringInstrumentation.callActivityOnResume(MonitoringInstrumentation.java:564) at android.app.Activity.performResume(Activity.java:6783) at android.app.ActivityThread.performResumeActivity(ActivityThread.java:3406) at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:3469) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1527) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6119) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
,
Feb 28 2018
I'll see if I can figure out why this is happening.
,
Mar 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/147ec4dff4656fdd8b54e3db577eaf988997820e commit 147ec4dff4656fdd8b54e3db577eaf988997820e Author: Michael Thiessen <mthiesse@chromium.org> Date: Thu Mar 01 02:07:45 2018 VR: Fix wrong Activity being resumed sometimes when cancelling animation Android task stacks are a confusing mess. For some reason starting the animation cancel activity in its own task stack is leading to a less- recent CTA instance being resumed instead of the CCT that invoked the animation cancel. We can fix this by not starting the animation cancel in a new task stack. Bug: 817476 , 817503 Change-Id: I99fe4583c02c9c5c2333697166e6e4081ad4f818 Reviewed-on: https://chromium-review.googlesource.com/941912 Reviewed-by: Yash Malik <ymalik@chromium.org> Commit-Queue: Michael Thiessen <mthiesse@chromium.org> Cr-Commit-Position: refs/heads/master@{#539984} [modify] https://crrev.com/147ec4dff4656fdd8b54e3db577eaf988997820e/chrome/android/java/src/org/chromium/chrome/browser/vr_shell/VrShellDelegate.java
,
Mar 1 2018
,
Mar 1 2018
,
Mar 1 2018
,
Jul 4
,
Aug 29
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by mthiesse@chromium.org
, Feb 28 2018