This might be a flake. Monitoring.

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

commit b5c328cf0d9d426eeb50f47269ebc338cdbb71bb
Author: wfh <wfh@chromium.org>
Date: Tue Sep 13 16:30:13 2016

Disable interactive_ui_tests on Win10 FYI bot.

They're failing anyway, and it masks any other real failures.

BUG=640996

Review-Url: https://codereview.chromium.org/2332223002
Cr-Commit-Position: refs/heads/master@{#418270}

[modify] https://crrev.com/b5c328cf0d9d426eeb50f47269ebc338cdbb71bb/testing/buildbot/chromium.fyi.json

interactive_ui_tests are still running on the FYI bot and I have no idea why - can someone assist?

https://build.chromium.org/p/chromium.fyi/builders/Win%2010%20Fast%20Ring

Sigh. It looks like the patch was applied incorrectly, and you caused it to stop running on the new "ThinLTO Linux ToT" builder instead.

This is a known problem that shows up intermittently due to the highly repetitive nature of these files.

Sad face. sorry :( Should I fix this now?

https://codereview.chromium.org/2337343002 is up and I have started trybots so please look at and CQ asap before someone else changes the file.

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

commit c2b99c624dab73f9a91dd54463aeab808eeefbb6
Author: wfh <wfh@chromium.org>
Date: Wed Sep 14 01:36:33 2016

Fix bad merge of b5c328c - disable interactive_ui_tests on Win10.

BUG=640996

Review-Url: https://codereview.chromium.org/2337343002
Cr-Commit-Position: refs/heads/master@{#418449}

[modify] https://crrev.com/c2b99c624dab73f9a91dd54463aeab808eeefbb6/testing/buildbot/chromium.fyi.json

The suite is running again on the FYI bot now. These tests failed in the most recent build:

BookmarkBarViewTest2.HideOnDesktopClick
FindInPageTest.SelectionRestoreOnTabSwitch
OmniboxApiTest.DeleteOmniboxSuggestionResult
SendMouseMoveUITest.Probe
UserDataDowngradeBrowserNoMSITest.Test

There's something silly going on with mouse event sending:

[10276:6844:1117/033000.760:ERROR:ui_controls_internal_win.cc(225)] Mouse moved to (181, 408) rather than (0, 0); check the math in SendMouseMoveImpl.

That's waaay more than a rounding error. I'm not sure what's going on. It would be worth connecting to the bot and running SendMouseMoveUITest.Probe to see what's happening.

StatusTrayStateChangerWinTest.TraySizeApiTest fails on Win10 as well. Maybe just a matter of the final expectation being updated?

Huh. Maybe a timing issue. Work locally most of the time.

UserDataDowngradeBrowserNoMSITest.Test failed for my CL try jobs too: https://logs.chromium.org/v/?s=chromium%2Fbb%2Ftryserver.chromium.win%2Fwin10_chromium_x64_rel_ng%2F30746%2F%2B%2Frecipes%2Fsteps%2Finteractive_ui_tests__with_patch__on_Windows-10-14393%2F0%2Flogs%2FUserDataDowngradeBrowserNoMSITest.Test%2F0

[7160:2116:1120/110458.018:FATAL:optional.h(204)] Check failed: !storage_.is_null_.
Backtrace:
	base::debug::StackTrace::StackTrace [0x00007FF766106144+36]
	logging::LogMessage::~LogMessage [0x00007FF76604C76E+94]
	base::Optional<int>::value [0x00007FF768338789+89]
	ThemeServiceWin::GetDefaultColor [0x00007FF769468632+162]
	ThemeService::GetColor [0x00007FF7677B5C66+198]

As this bug predates the code in comment 14, I've split that off to  bug 787073 .

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

commit 05ff85c02778369dd6ac93c7797eb001a3c49b9c
Author: Gabriel Charette <gab@chromium.org>
Date: Thu Jan 10 18:11:13 2019

[ui_controls] Refactor InputDispatcher's memory model.

Extracted from https://chromium-review.googlesource.com/c/chromium/src/+/1392178

Removes manual ref-counting in favor of just-in-time creation + unique
self ownership. Required for WeakPtr scheme in follow-up CL.

Note: Patch set 1 tried to add checks that confirm the pre-existing assumptions
made by InputDispatcher (i.e. that the input was successfully sent) but some
scenarios fail those tests. To be investigated as a follow-up.

R=grt@chromium.org, sadrul@chromium.org

Bug:  892228 , 640996
Change-Id: Ia1df67e809845a228c4a9a6b77da08de037cf621
Reviewed-on: https://chromium-review.googlesource.com/c/1400950
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621639}
[modify] https://crrev.com/05ff85c02778369dd6ac93c7797eb001a3c49b9c/ui/base/test/ui_controls_internal_win.cc

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

commit 86c995c3718c4c14997a8a7b6422e56bad747685
Author: Gabriel Charette <gab@chromium.org>
Date: Thu Jan 10 18:25:42 2019

[ui_controls] Fix InputDispatcher's handling of KeyboardProc

Extracted from
https://chromium-review.googlesource.com/c/chromium/src/+/1392178

While this CL doesn't fix all the flakiness encountered (i.e. doesn't
deal with pending WM_KEYUPs flakily being interpreted as the just-sent
key up events) : it's a strict improvement by addressing two fundamental
flaws of the existing InputDispatcher.

 1) Use bit 31, not 30, to determine key up events.
 2) Also expect key ups for modifiers.

While (2) isn't a complete fix, it might actually help reduce the
incidence of flakes caused by :
  A) SendInput and don't wait for them to complete
  B) SendInput and DO wait for them to complete
  (can flake when wait (B) unintentionally observes incomplete (A))
Without (2) (A) could also be a  SendInput WITH an InputDispatcher since
modifiers weren't waited upon and hence could leak into (B).

R=grt@chromium.org, sadrul@chromium.org

Bug:  892228 , 640996
Change-Id: I8848193ee4d53a7c60c845a9b02562662715ae3c
Reviewed-on: https://chromium-review.googlesource.com/c/1401223
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621649}
[modify] https://crrev.com/86c995c3718c4c14997a8a7b6422e56bad747685/ui/base/test/ui_controls_internal_win.cc

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

commit ec52747a5abc25a862843edca761104b3c319764
Author: Gabriel Charette <gab@chromium.org>
Date: Mon Jan 14 16:16:49 2019

[ui_controls] Unflake Send*NotifyWhenDone() on Windows

ui_controls::Send*NotifyWhenDone() can be flaky when invoked after
ui_controls::Send*() as the former can decide to notify based on
observing a yet-to-be-processed event from the latter (or even a
yet-to-be-processed event emitted by unrelated code) and thus notify too
early, resuming and testing conditions that have yet to be met.

Solution: defer the notification if the system queue has pending events
of the same type awaiting dispatch.

Note: mouse move can be repeated indefinitely during a drag, as such we
consider a mouse move complete when it hits the target regardless of
remaining mouse move messages in the queue.

@ BUG OWNERS : This might unflake many currently disabled tests. I've
CC'ed interactive_ui_tests + Windows bugs, please try to re-enable your
test after this CL if you think it might be related.

Bug:  892228 , 640996, 897801,893078,876224,875443,873110,852786,850343,848049,846695,840369,798492,756338,751031,665296,651906,499858,468660,419468,238347,131612,106489,97777,92467
Change-Id: I548856a3948ff71a145435799b4ba3e689561f14
Reviewed-on: https://chromium-review.googlesource.com/c/1392178
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#622470}
[modify] https://crrev.com/ec52747a5abc25a862843edca761104b3c319764/chrome/browser/ui/views/bookmarks/bookmark_bar_view_test.cc
[modify] https://crrev.com/ec52747a5abc25a862843edca761104b3c319764/ui/base/test/ui_controls_internal_win.cc