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

Issue 903402 link

Starred by 1 user

Issue metadata

Status: Closed
Owner:
Last visit > 30 days ago
Closed: Jan 15
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug
Proj-VR
Proj-XR
Proj-XR-VR



Sign in to add a comment

Multiple VR Browser tests failing due to crashing tab

Project Member Reported by bsheedy@chromium.org, Nov 8

Issue description

A number of the VR Browser tests have started failing consistently on N and O as of https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Oreo%20Phone%20Tester/1712.

The reported erroris an AssertionError due to the tab crashing.
 
Labels: OS-Android
The currently failing tests are:

WebXrVrInputTest#testInSessionPermissionRequestsIncognito
VrBrowserNavigationTest#testNavigationButtons
VrBrowserNavigationTest#testUrlEntryTriggersNavigationIncognito
VrBrowserNavigationTest#testBackDoesntBackgroundChrome
WebXrVrInputTest#testAppButtonLongPressDisplaysPermissionsIncognito
WebXrVrTabTest#testPermissionsInOtherTabIncognito
WebXrVrTabTest#testPermissionsInOtherTab

However, I've been unable to reproduce locally on a Pixel 2 w/ O so far.
Owner: nek...@chromium.org
It reproes on swarming, so I used that to bisect. Culprit is https://chromium-review.googlesource.com/c/1295769.

Logcat points to the following line as the cause of the crash
F chromium: [FATAL:hash_table.h(1090)] Check failed: (HashTableKeyChecker< HashTranslator, KeyTraits, HashFunctions::safe_to_compare_to_empty_or_deleted>::CheckKey(key)).
although I've been unable to get a symbolized stack so far.

Any ideas nektar@?
I am really puzzled about this.
Project Member

Comment 4 by bugdroid1@chromium.org, Nov 9

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

commit f6b72e6ccca7c64e6127281f1b73beafe72a3b87
Author: Nektarios Paisios <nektar@chromium.org>
Date: Fri Nov 09 23:09:44 2018

Reland: Marks the document object as busy while it is still loading

Changes in the reland compared to the original patch:
Switched to using GetRoot instead of Root() which might prevent the use of an uninitialized root object.

Original description:
Screen readers want to have a reliable way to know whether a document is still loading so as to ignore events coming from it.
The current change can be made irrespective to whether we will mark the document as loaded when HTML parsing has started or when the "interactive" readyState has been entered.

R=dmazzoni@chromium.org, aleventhal@chromium.org

Bug: 897177,  903402 
Change-Id: I681883999918ffdd32fc11d2f691b659c7e91149
Reviewed-on: https://chromium-review.googlesource.com/c/1327745
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607017}
[modify] https://crrev.com/f6b72e6ccca7c64e6127281f1b73beafe72a3b87/content/browser/accessibility/browser_accessibility_manager.cc
[modify] https://crrev.com/f6b72e6ccca7c64e6127281f1b73beafe72a3b87/content/renderer/accessibility/blink_ax_tree_source.cc

Project Member

Comment 5 by bugdroid1@chromium.org, Nov 12

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

commit d75cb3836e9681afc799e7c7ae7101e9f1ad267f
Author: Brian Sheedy <bsheedy@chromium.org>
Date: Mon Nov 12 20:58:22 2018

Revert "Reland: Marks the document object as busy while it is still loading"

This reverts commit f6b72e6ccca7c64e6127281f1b73beafe72a3b87.

Reason for revert: Still causing  https://crbug.com/903402 

Original change's description:
> Reland: Marks the document object as busy while it is still loading
> 
> Changes in the reland compared to the original patch:
> Switched to using GetRoot instead of Root() which might prevent the use of an uninitialized root object.
> 
> Original description:
> Screen readers want to have a reliable way to know whether a document is still loading so as to ignore events coming from it.
> The current change can be made irrespective to whether we will mark the document as loaded when HTML parsing has started or when the "interactive" readyState has been entered.
> 
> R=​dmazzoni@chromium.org, aleventhal@chromium.org
> 
> Bug: 897177,  903402 
> Change-Id: I681883999918ffdd32fc11d2f691b659c7e91149
> Reviewed-on: https://chromium-review.googlesource.com/c/1327745
> Commit-Queue: Nektarios Paisios <nektar@chromium.org>
> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#607017}

TBR=dmazzoni@chromium.org,nektar@chromium.org,aleventhal@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 897177,  903402 
Change-Id: I18b4bae20db26dc26934abb08e97df0b8a151465
Reviewed-on: https://chromium-review.googlesource.com/c/1331145
Reviewed-by: Brian Sheedy <bsheedy@chromium.org>
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607319}
[modify] https://crrev.com/d75cb3836e9681afc799e7c7ae7101e9f1ad267f/content/browser/accessibility/browser_accessibility_manager.cc
[modify] https://crrev.com/d75cb3836e9681afc799e7c7ae7101e9f1ad267f/content/renderer/accessibility/blink_ax_tree_source.cc

Status: Assigned (was: Untriaged)
Can we close this?
Status: Closed (was: Assigned)
Probably safe to do so. If it re-appears, I'll re-open.

Sign in to add a comment