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

commit 5f24b9f8d3235da25621a579bbd9f05408c1302e
Author: Sebastien SG <sebsg@chromium.org>
Date: Fri Mar 30 16:24:56 2018

Disable SendMouseMoveUITest.Probe flaky on Win

Bug:  827549 
Change-Id: Id6575363580a30d196e81926ba37c4e6bd1829fa
Tbr: grt@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/987523
Reviewed-by: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Commit-Queue: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547178}
[modify] https://crrev.com/5f24b9f8d3235da25621a579bbd9f05408c1302e/chrome/browser/ui/send_mouse_move_uitest_win.cc

Huh. The test doesn't pass locally for me, either. I'm not yet sure if it's due to a change in Chrome or in the Win10 Fall Creators Update.

+folks

As far as I can tell, MS has broken SendInput(INPUT_MOUSE) in Fall Creators Update. I haven't found anything in MSDN explicitly stating this, but it no longer appears to work. To boot, SendInput is listed in the "Legacy User Interaction Features" docs. Does anyone have a contact there to verify that it's intentionally broken (vs. us using it wrong)? Is there a replacement API?

interactive_ui_tests depend on this today to position the mouse.

I've heard nothing about this. The only reference I could find to SendInput was this change which you landed last year:

https://chromium-review.googlesource.com/686898

Maybe something broke the far-too-subtle math again?

IIRC, SendInput is very sensitive to the permission level of the calling process. 

I don't have 1709 running on my dev box. Is the API failing and if so, what's the last error?

I'll have to test a bit more to be sure, but what I was seeing was that SendInput returned non-zero and our WH_MOUSE hook was being called, yet the mouse itself didn't change position. In other words, GetCursorPos returned the same coords before we called SendInput and after the hook was invoked.

As far as I can tell, the failures are unrelated to any code changes. The test started failing when the bot was upgraded. It certainly has nothing to do with the fixes I landed last year.

If you're curious, you can download build artifacts from isolate magic and run them locally with "--gtest_filter=*.Probe --gtest_also_run_disabled_tests"

Confirmed:
- SendInput returns 1 (the number of INPUT elements it's given)
- our WH_MOUSE hook fn is being called ~immediately after SendInput is called
- the actual mouse position is not changed by SendInput

Of note:
- we're installing the hook locally in our process on the test's UI thread
- the hook fn is being called, so it makes sense that it's being installed properly
- if i wobble the mouse around, the correct values are seen by the hook fn

It really seems as if SendInput with MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE is no longer doing its thing.

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

commit f40c30dcf3590ad29eb9e7abc686a06f78383712
Author: Greg Thompson <grt@chromium.org>
Date: Tue Apr 10 20:49:25 2018

Fix ui_controls::SendMouseEvents* on Win10 Fall Creators Update.

A change in Windows made absolute moves to coordinate 0,0 not work. It
seems that moving to 1,1 (normalized) does the trick. 1,1 will round
down to 0,0 for any display we care about.

BUG= 827549 

Change-Id: I76fac0313901ba68bb35ed624c475aed23592029
Reviewed-on: https://chromium-review.googlesource.com/1004734
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549639}
[modify] https://crrev.com/f40c30dcf3590ad29eb9e7abc686a06f78383712/chrome/browser/ui/send_mouse_move_uitest_win.cc
[modify] https://crrev.com/f40c30dcf3590ad29eb9e7abc686a06f78383712/ui/base/test/ui_controls_internal_win.cc