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

Issue 863067 link

Starred by 3 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jul 24
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

issue 802294

Sign in to add a comment

virtual/.../window-focus-self.html in webkit_layout_tests failing on chromium.webkit/WebKit Win10

Project Member Reported by, Jul 12

Issue description

Filed by on behalf of

virtual/.../window-focus-self.html in webkit_layout_tests failing on chromium.webkit/WebKit Win10

Builders failed on: 
- WebKit Win10:

Increasing flakiness (9 out of the last 24 runs). Failing with "FAIL: Window was focused"
Components: Blink>DOM Blink>HTML>Focus
Project Member

Comment 3 by, Jul 12

The following revision refers to this bug:

commit a7be9cc2e39f872aeb8e03afb7d0aabf92ffde03
Author: Kim Paulhamus <>
Date: Thu Jul 12 16:49:02 2018

Mark window-focus-self as flaky on Win10

Bug:  863067 
Change-Id: I9f043eec8363dbb26ccaa8d901321e0d579f1a4f
Commit-Queue: Kim Paulhamus <>
Reviewed-by: Kim Paulhamus <>
Cr-Commit-Position: refs/heads/master@{#574600}

Labels: -Sheriff-Chromium
Components: -Blink>DOM -Blink>HTML>Focus Blink>Input
Labels: Type-Bug
Status: Untriaged (was: Available)
Non-virtual version is very stable.  This is specific to user-activation-v2.

Status: Assigned (was: Untriaged)
Project Member

Comment 7 by, Jul 13

The following revision refers to this bug:

commit 5427394bb739114e0a03c80594fcf4271fa461af
Author: Kim Paulhamus <>
Date: Fri Jul 13 00:31:23 2018

Disabling the virtual window-focus-self test, not the non-virtual

Bug:  863067 
Change-Id: I913685da055480d9cddea105808a16fd7e70facd
Reviewed-by: Kim Paulhamus <>
Commit-Queue: Kim Paulhamus <>
Cr-Commit-Position: refs/heads/master@{#574790}

Blocking: 802294
Labels: UserActivation
kpaulhamus@: Wondering how to access the failure logs.  The link in #c1 doesn't seem to provide details unless I am missing something.

For records: the test has been flaky on Mac even w/o UAv2 enabled:  Issue 816766 .

Nm, found a log it:

Looks like the windows gets "blur" and then "focus" events, while it expected only the first one.

We get the exact same outcome in mac ( Issue 816766 ):

Components: -Blink>Input Blink>HTML>Focus
Thanks for looking! I'll direct this towards the same component. Feel free to unassign yourself.
Owner: ----
Status: Available (was: Assigned)
Status: Assigned (was: Available)
kochi@, I remember you have recently investigated a similar issue. Could you triage?
This seems to be a different problem than issue 859605, as the other issue
is about Element.focus(), while window.focus() runs completely different
code path.

window.focus() involves renderer<->browser IPC, so checking focus/blur event
on window against window.focus() can't be completely synchronous as opposed
to Element.focus().

The test in question relies on the event is dispatched (or not dispatched)
immediately using `setTimeout(, 0)`, which seems to me the source of flakiness.

>'javascript:window.focus()', '_self', '');
>        setTimeout(function() { testRunner.notifyDone(); }, 0);
Project Member

Comment 17 by, Jul 18

The following revision refers to this bug:

commit cea59c5edf0cf821af87ee665a9448d19a07f9df
Author: Christian Dullweber <>
Date: Wed Jul 18 14:03:45 2018

Disable window-focus-self.html on Windows

fast/dom/Window/window-focus-self.html is failing on Windows.

Bug:  816766 ,  863067 
Change-Id: Ie54d5722b6c9c76d548d43a190ab827f051cdeb9
Commit-Queue: Christian Dullweber <>
Reviewed-by: Christian Dullweber <>
Cr-Commit-Position: refs/heads/master@{#576029}

My analysis in comment 16 looks wrong.

The original intention of this test when it was introduced:

checks opening a popup window against "_self" explicitly.
Probably the code was lost at some point - will investigate.
 Issue 816766  has been merged into this issue.
During initialization, the code to focus main frame (for delivering input events
etc.) sends IPC to focus, but the actual handling of this IPC could be
delayed after the test function is run, and occasionally "focus" event handler
is unexpectedly called for it, not the focus event originating from the script.
is the place where the IPC is sent.

I'll make a change to the test to delay the execution of test function
after initial rendering.
Project Member

Comment 21 by, Jul 23

The following revision refers to this bug:

commit 44bc78241ecd613537c76e0df0c3a495ab01be01
Author: Takayoshi Kochi <>
Date: Mon Jul 23 08:44:31 2018

Delay the test execution to avoid flakiness

The frame's initialization code focuses the content from browser
process via an IPC (browser->renderer), but its handling in the
renderer can be delayed until after the test code script execution
is started.

This caused the test to have a race condition, that a focus event
is delivered where it is not expected, and resulted the flakiness.
The test can fail on the initial use of content_shell process.

Delay the execution of test function so that it will not be
affected by the frame initial focus event.

Bug:  863067 
Change-Id: I475d912b0e9baffa3917212b2fc0735189381cb8
Commit-Queue: Takayoshi Kochi <>
Reviewed-by: Kent Tamura <>
Cr-Commit-Position: refs/heads/master@{#577124}


Sign in to add a comment