Able to reproduce this Mac 10.12.3 with chrome stable #57.0.2987.110 and Canary #59.0.3046.0
Issue is broken in M51.

Bisect Info:
===========
Good build : 51.0.2673.0 ,  Revision Range - 380313
Bad build  : 51.0.2678.0 ,  Revision Range - 380962

After executing the old bisect script , i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/cb9d633e2f1f1f13881899fa92f356bf8cd79e02..fd7ede807eb0e64820c805e8d5d0caf7ba9c5516

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/chromium/src/+/fd7ede807eb0e64820c805e8d5d0caf7ba9c5516

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

Note:
Not able to reproduce this issue on Windows 10 and Ubuntu 14.04

bokan@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Deleted: Issue 703213 - Good.mp4 2.2 MB

	Issue 703213 - Good.mp4 2.2 MB View Download

Deleted: Issue 703213 - Bad.mp4 982 KB

	Issue 703213 - Bad.mp4 982 KB View Download

Lowering priority since this has been around for a while without much user complaint.

+sahel@: I suspect this is because we dispatch the wheel specifically to the scrollbar and the handling there is somewhat different. Is there any reason to dispatch wheels to the scrollbar rather than the element/frame itself?

I am not sure if we dispatch the wheel events to the scrollbar.
In https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/input/EventHandler.cpp?l=1280 we dispatch it to the document and in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutView.cpp?q=SetInnerNode&dr=C&l=156 if the hit test result have scrollbar, the innerNode is set to its parent.

GestureScrollEvents are handled by scrollbar, though. This is for updating scroll_pos of the scrollbar and moving the Thumb. Once wheel scroll latching is enabled, when the cursor is over the scrollbar and the scrollbar is visible, the scroll latches to the scrollbar even when the scroller has already hit its content in the beginnning of scroll sequence. If we dispatch the scroll event to the element/frame itself, we won't have the same latching behavior on GSB.

Sorry, I confused my terminology. I mean that the scrollbar handles the Gesture events :)

But the scrollbar reacts to changes in scroll position of the ScrollableArea its attached to so it should have no need to do anything itself for a GestureScroll right? i.e. Programmatically setting the scroll offset from JS doesn't ever explicitly go into Scrollbar code but the thumb is updated accordingly.

If I'm understanding the latching behavior you describe, that means that we latch differently based on whether you're over a scrollbar or the content area? IMHO, we shouldn't do that. I think it would make everything simpler if we simply avoided giving the Gesture events to the scrollbar and changed the latching behavior accordingly. WDYT?

This seems to fixed in latest Canary. I can't reproduce it any longer in Version 60.0.3078.0 on OSX 10.12.4.

Has been a fix landed for this issue in the meanwhile?

This is fixed in Chrome 60.0.3112.78 stable, but it is back again in latest Canary 62.0.3169.0. This happens now too, when "Show Scroll bar Automatically based on mouse or trackpad" is enabled.

Comment 4 is not valid anymore. With below fix scrollbars don't handle scrolling when we are autoscrolling or scrolling by wheel/trackpad over scrollbars.

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