Issue 593389  has been merged into this issue.

(Note repro steps assume "Natural scrolling" is DISABLED in System Settings > Mouse and Touchpad > Touchpad.  I don't remember if that was the default or not.) 

Was just about to file a bug on this. Also experiencing this in Chrome 51 & 52 on a Lenovo Linux laptop when scrolling with the touchpad.

Created simple test case and screencast.
https://jsfiddle.net/a8wk2m6t/

At no point do I scroll upwards in the video, after clicking on the page the next time I scroll it jumps up the page.

Deleted: scroll-jumping.webm 2.4 MB

scroll-jumping.webm 2.4 MB Download

Bisected locally down to this change: https://codereview.chromium.org/1883853002

Can this change be reverted and merged? It's making Chrome on Linux laptops very painful to use.

Looks like that change was merged into 51.

How about I add a chrome://flags flag to disable high precision scrolling? I've just finished exams so I'll have a go at the described repro as well, see if I can get this to happen. 

I confirm this bug on Ubuntu 16.04 / Lenovo Thinkpad T460p / 52.0.2743.33 (Official Build) beta (64-bit). For me at least there's easier steps to reproduce:

* Open any webpage and scroll down below the very top of the page
* Use the physical buttons to left or middle click anywhere on the page
* Initiate a two finger scroll with the touchpad 

The page will scroll back up, often all the way back to the top of the page. 

This renders Chrome almost unusable for me because middle click to open in a new tab followed by two finger scroll is something I do all day, and it triggers this bug. 

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

commit f7e731e7822967ab2d22530ea8d8487cf623ae3b
Author: w.shackleton <w.shackleton@gmail.com>
Date: Wed Jun 29 22:38:45 2016

Disabled xinput2 until edge cases can be fixed.

Forces all input devices to use xinput1, the previous path,
until all the kinks are worked out with the new xinput2 path.

BUG= 616308 

Review-Url: https://codereview.chromium.org/2108283002
Cr-Commit-Position: refs/heads/master@{#402966}

[modify] https://crrev.com/f7e731e7822967ab2d22530ea8d8487cf623ae3b/ui/events/devices/x11/device_data_manager_x11.cc

I'm requesting merge to M52. Given that it's quite late, to justify this for TPMs, the above CL simply forces input devices to use the old path that was used prior to M51 so it should be low risk and affects only Linux (and some non-ozone CrOS devices if I understand correctly. sadrul@, is this correct?). This issue was causing significant pain for users on devices with multiple mice, like laptops with a track point and touchpad.

(Note, I put the wrong bug on the CL description, this should really have gone into  issue 609748  which this is a dup of)

Your change meets the bar and is auto-approved for M52 (branch: 2743)

bokan@, is this verified on canary & is it safe to merge in to the M52 branch ?
Requesting the above information as we do not have X1 carbon with linux with us to verify it on ToT build.

Unfortunately, we don't have a canary channel on Linux and dev channel still hasn't caught up.

Chatted offline with govind@. I have verified in ToT that the fix works as expected. It should be low risk since we're switching input to the path that was used exclusively pre M51 and is still used for low-resolution wheel devices in M52 currently. This patch just makes all devices use the old path again (i.e. touchpads).

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

commit f43fd606fed2ff91d4628a3f38ea2a0c83841644
Author: David Bokan <bokan@chromium.org>
Date: Fri Jul 01 20:14:50 2016

Disabled xinput2 until edge cases can be fixed.

Forces all input devices to use xinput1, the previous path,
until all the kinks are worked out with the new xinput2 path.

BUG= 616308 

Review-Url: https://codereview.chromium.org/2108283002
Cr-Commit-Position: refs/heads/master@{#402966}
(cherry picked from commit f7e731e7822967ab2d22530ea8d8487cf623ae3b)

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

Cr-Commit-Position: refs/branch-heads/2743@{#571}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/f43fd606fed2ff91d4628a3f38ea2a0c83841644/ui/events/devices/x11/device_data_manager_x11.cc

Disabling CL has been merged to M52. M52 should now use the old xinput1 path, meaning step-wise wheel scrolling again (though smooth scrolling animations make this less noticeable now).

 Issue 609748  has been merged into this issue.

bokan@, could you please verify this fix on latest Dev#53.0.2785.8 if required? I am seeing it has already been verified on ToT and we have recently branched (2785) the above Dev form ToT.

Thank you!

Will do once Dev channel is pushed. My dev is still on 53.0.2783.2 and omahaproxy says as much.

Ok, I'm now at 53.0.2785.8 and have verified the disable CL. Everyone, if you could, please try out the latest dev-channel, let me know if you're still seeing issues.

FYI, for Chrome 52, 52.0.2743.64 and newer has the fix, but 52.0.2743.60 is the current release. Hopefully a new 52.x release will be pushed out next week.

This is in the latest M52 beta. I've confirmed the fix locally.

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

commit 5d5004de45d12a79de5dcd1a8e217dce3a1dc190
Author: w.shackleton <w.shackleton@gmail.com>
Date: Tue Jul 26 14:38:27 2016

Added a command line switch to disable xinput2, enabled xinput2 by default

I added the switch --disable-high-precision-scrolling to disable xinput2
scrolling functionality. The switch is named high-precision rather than smooth
to avoid confusion with the scroll interpolation feature known as smooth
scrolling.

This CL also re-enables xinput2. I believe that all the bugs that caused it to
be disabled are now fixed (once https://codereview.chromium.org/2077163003/ is
in) but this switch will help mitigation if I am wrong (which I suspect I might
be given the range of prior bugs).

I've added two new files---have I added them in all the correct gyp/GN
locations?

BUG= 616308 

Review-Url: https://codereview.chromium.org/2153683002
Cr-Commit-Position: refs/heads/master@{#407792}

[modify] https://crrev.com/5d5004de45d12a79de5dcd1a8e217dce3a1dc190/ui/events/devices/x11/device_data_manager_x11.cc
[modify] https://crrev.com/5d5004de45d12a79de5dcd1a8e217dce3a1dc190/ui/events/devices/x11/device_data_manager_x11.h

 Issue 630892  has been merged into this issue.