Can you repro this with the Chrome app?

Do you mean using the chrome app as client? I can take a look when I get home. Currently I don't have Windows host in the company...

Looks like this can't be reproduced in Chrome.
It doesn't feel much different in a high latency network so we may just mark this as wontfix for now.

We should still fix this even if it repros only with Android client. One problem I see in remoting/host/input_injector_win.cc is that it doesn't handle properly events that have both wheel_delta_x() and wheel_delta_y(). I think we should be injecting two events in that case, but that's not what InputInjectorWin does. Not sure if that issue actually causes the problem reported here, but it's likely to be related. 

Zijie, can you take a look?

Talked offline with Yuwei
1. On Windows 10 host, the TouchInputStrategy is used instead of SimulatedTouchInputStrategy. Talked offline with Joe, TouchInputStrategy was designed to ignore onScroll events, since remote host should do the simulated work as what we have in ScrollAnimationJob.
2. On Windows host, besides what Sergey mentioned, one more known issue is wheel_clicks_x and wheel_clicks_y are ignored. According to msdn (http://shortn/_ztCXNKnrCo), we should be able to handle wheel clicks correctly.

I thought we just sent the wheel_clicks to allow hosts that can't do
pixel-granularity scrolling to behave sensibly? i.e. it's intentional that
the Windows host ignores them?

But x11 injector for linux prefer ticks (typo in last comment, clicks -> ticks) than delta.

(I assume the comments above refer to wheel_ticks where they say wheel_clicks).

As far as I can tell Android only sets wheel_delta, and windows only uses wheel_delta, so I don't see how windows ignoring wheel_ticks may be a problem here.
All of our clients set wheel_delta and the host knows how to use it on all platforms. webapp also sets wheel_ticks and OSX/X11 ignores wheel_delta when wheel_ticks is set.

Why do OSX & X11 ignore wheel_delta when wheel_ticks is set?  Is there some
up/down-scaling of pixel-level scroll deltas we're missing for high-DPI
devices, for example, that means ticks work better?

Actually on OSX we also use only delta, same as on Windows. Ticks are preferred only with X11.

If I remember correctly it's because when user scrolls one tick on the client it's expected that the host gets the same one tick. Tick size is not the same on all platforms, so if the host was preferring delta then it wouldn't work correctly: it would appear as if wheel is ignored sometimes. See  bug 180715 .
It wouldn't be a problem if it was possible to inject delta values, but AFAIK it's not possible with X11. From its point of view the wheel is just an extra pair of buttons.

I still doubt if it would be better to prefer tick on each platform. i.e. With a same model of mouses on different clients, and remoting to a same host, performing one tick results into different scrolling behavior.

But for CL 1865543003, I focus on the issue, that Windows host cannot inject horizontal wheel and vertical wheel events together.

We use pixel deltas rather than wheel ticks because trackpads often support
more fine-grained scrolling.

Yes, but that's for the client side I believe. i.e. The client may not support wheel tick input.

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

commit 0d2570c7d26fd026fa7f720aef5b0d4d049c643d
Author: zijiehe <zijiehe@chromium.org>
Date: Thu Apr 07 00:05:32 2016

Update input_injector_win.cc to support injecting wheel-x and wheel-y events together

BUG= 598434 

Review URL: https://codereview.chromium.org/1865543003

Cr-Commit-Position: refs/heads/master@{#385594}

[modify] https://crrev.com/0d2570c7d26fd026fa7f720aef5b0d4d049c643d/remoting/host/input_injector_win.cc