I don't think we can simply change the EventSender semantics here.  There's two different concepts (that are easy to conflate):
1) injecting WebInputEvents into blink for testing blink
2) injecting synthetic events (eg. ui::Event) into the browser for testing the combined content/blink/compositor code

The API probably isn't the same for them, eg:
 - #2 has no way to generate "gestures" that is distinct from "touches"
 - #1 can set bits like "WebMouseWheelEvent.canScroll" and "WebTouchEvent.hasExceededSlopRegion" but #2 cannot)
 - #1 can be a synchronous API while #2 is definitely async

This means it's often non-trivial to convert a test using #1 to using #2.  So really I think what we want is to switch some tests away from using EventSender to using something else that is clearly different.

I think Rick is correct here.

It isn't entirely clear to me how we make the decision between sending event directly to the renderer, vs using browser-level synthetic input.

We should probably establish some rough guidelines at some point, I think we'll want to continue using both approaches.

Right I wonder if we could actually have a "Native Event Sender" which could be a completely different object than EventSender. And ultimately it would generate true platform events.

Ultimately for keyboard; specifically IME it would be useful if these events went through those engines.

Yep, I think the guidelines are similar to those for deciding if you want a unit test or integration test.  If you're trying to test the whole system together, then use NativeEventSender.  But if you just want to exercise some specific blink code, then a unit test may be better.

Eg. there may be cases where content sending a surprising / invalid event sequence causes blink to crash, when we fix code in blink for that it's probably an input unit test we want to use to test it (effectively mocking out the content and UI layers).   Similarly if you're testing a scenario that is special only because of code in blink (i.e. no reason to test the content side of this scenario), then it may be simpler to just use a unit test because it lets your write everything synchronously.

Also at play here is which of our tests should really be interop tests (web-platform-test).  I suspect many tests in fast/events should really be superseded by input WPT tests (which will also have some mechanism for integration-level synthetic input, and NOT a mechanism for unit testing).

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Over to Navid for triage.

We are moving away from event sender to wpt test driver one test at a time. This work is making progress slowly but surely.