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

Issue 753192 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

snav-not-rightof.html and snav-symmetrically-positioned.htm loose Down key stroke on Win10

Project Member Reported by shimazu@chromium.org, Aug 8 2017

Issue description

fast/spatial-navigation/snav-overlapping-elements.html has been flaky according to the flakiness dashboard:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=webkit_tests&tests=fast%2Fspatial-navigation%2Fsnav-overlapping-elements.html


 
Components: -Blink>DOM Blink>Focus

Comment 2 by kochi@chromium.org, Aug 8 2017

Cc: kochi@chromium.org
Owner: hu...@opera.com
Hugo, could you take this?

Comment 3 by hu...@opera.com, Aug 14 2017

Cc: -kochi@chromium.org hu...@opera.com
Labels: -OS-Mac
Owner: kochi@chromium.org
Summary: snav-not-rightof.html and snav-symmetrically-positioned.htm loose Down key stroke on Win10 (was: Flaky layout test: fast/spatial-navigation/snav-overlapping-elements.html)
I got a little confused when looking at the test result page. I see two flaky snav tests, neither is snav-overlapping-elements.html. They both happen on Windows 10 only.

1. fast/spatial-navigation/snav-not-rightof.html @
 - https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win10/builds/24428
 - https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win10/builds/24378

2. fast/spatial-navigation/snav-symmetrically-positioned.html @
  https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win10/builds/24412

When looking at snav-not-rightof-actual.txt I see:

PASS gFocusedDocument.activeElement.getAttribute("id") is "e1"
FAIL gFocusedDocument.activeElement.getAttribute("id") should be e2. Was e1.
FAIL gFocusedDocument.activeElement.getAttribute("id") should be e2. Was e1.
FAIL gFocusedDocument.activeElement.getAttribute("id") should be e3. Was e2.
FAIL gFocusedDocument.activeElement.getAttribute("id") should be e3. Was e2.
FAIL gFocusedDocument.activeElement.getAttribute("id") should be e2. Was e1.
FAIL gFocusedDocument.activeElement.getAttribute("id") should be e2. Was e1.
PASS gFocusedDocument.activeElement.getAttribute("id") is "e1"

Focus moved correctly except at the first Down key (focus stayed in e1 so the remaining asserts fail as well).
Also snav-symmetrically-positioned-actual.txt indicates the first Down key stroke went missing.

Is "missing" key strokes on Windows a known cause for flakiness? Even tough the test runs on 'onload', my guess is that content_shell (sometimes -> flake) hasn't yet started up properly so the first Down stroke goes missing somewhere. This is tricky for me to debug because I only have a Linux workstation. Maybe someone who knows the Win10 test environment better could take this?
Components: Blink>HTML>Focus
Components: -Blink>Focus

Comment 6 by kochi@chromium.org, Oct 17 2017

Owner: ----

Comment 7 by hu...@vewd.com, Oct 31 2017

Cc: hu...@vewd.com xiaoche...@chromium.org kochi@chromium.org
 Issue 774688  has been merged into this issue.
Project Member

Comment 8 by sheriffbot@chromium.org, Oct 31

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: spatial-navigation
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)

Sign in to add a comment