To be clear I am observing this when using a mac wired mouse with a multi directional scroll wheel.

So further digging into the MouseWheelEvent::ProcessMouseAck I noticed:

1- If the source of the input is the trackpad/touchpad on my laptop, there is a RailsMode indication which is set through MouseWheelRailsFilter. When using the trackpad both delta_x and delta_y are always nonzero which jumps the condition of delta_x and hence organically, we never swap X & Y when shift is pressed.

2- If the source of the input is an hp mouse then the OS event seems to have already taken care of the direction, i.e., shift + scroll leads to nonzero delta along X and zero delta along Y.

3- If the source of the input is the apple mouse with omnidirectional wheel ball, then the OS event is the same as case (1), i.e., track pad except that only one of delta_x or delta_y is zero.

So we get case 2) for free since it never gets into the swapping code; but case 3) is buggy (the scenario is bug description happens).

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

commit 7fb58bbd8fa63eb7a9d7cb68761e367e5faf4f34
Author: Ehsan Karamad <ekaramad@chromium.org>
Date: Mon Jul 23 22:20:40 2018

Do not swap X & Y for for shift-scrolling on Mac

MacOSX scrollWheel event already provides the correct behavior. If the
event (physical) source has precise deltas and comes from a trackpad
or apple mouse then it has bidirectional deltas already and pressing
shift key should not swap the axis. If the source of the event is an
ordinary single-axis mouse, then the NSEvent already packs |delta_x|
instead of |delta_y| (for shift-scroll).

Also, it turns out that rails mode should only be used for trackpad. The
logic in MosueWheelRailsFilter uses an auto-regressive filter to smooth
out rails latching. This state is reset for a kPhaseScrollBegan. However,
apple mice would always have a phase of kPhaseNone. Since it never resets
it might lead to a large value in one axis (i.e., in y-axis after a
vertical scroll phase) and when scrolling in the other direction occurs,
the rails mode is set incorrectly. The side effects of this are zero
scroll deltas which also fires a DCHECK in mouse_wheel_event_queue.cc:
DCHECK(needs_update). To repro use an apple mouse and scroll vertically
and then horizontally using the bidirectional wheel.

Bug:  862661 

Change-Id: I4e5210454fe7352ab0230b312f44e1a374f22f0c
Reviewed-on: https://chromium-review.googlesource.com/1134434
Reviewed-by: ccameron <ccameron@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Ehsan Karamad <ekaramad@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577296}
[modify] https://crrev.com/7fb58bbd8fa63eb7a9d7cb68761e367e5faf4f34/content/browser/renderer_host/input/mouse_wheel_event_queue.cc
[modify] https://crrev.com/7fb58bbd8fa63eb7a9d7cb68761e367e5faf4f34/content/browser/renderer_host/input/mouse_wheel_event_queue_unittest.cc
[modify] https://crrev.com/7fb58bbd8fa63eb7a9d7cb68761e367e5faf4f34/content/browser/renderer_host/input/mouse_wheel_rails_filter_mac.cc

Marking as fixed following comment #4.