New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 47 users

Issue metadata

Status: Fixed
Merged: issue 609748
Closed: Jul 2016
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression

Sign in to add a comment

Issue 616308: Linux touchpad scroll jump

Reported by, May 31 2016 Project Member

Issue description

I've noticed this occasionally for a while and I think I finally have a consistent (but complicated) repro.

1. On X1 Carbon laptop with Ubuntu, visit:

2. Size the window so that "FrameView.h" is near the bottom.

3. Put the mouse pointer at the center of the window (around "Patch Set 2").

4. Start a downward scroll with a two-finger drag gesture that begins near the top of the touchpad.

5. Stop when the mouse pointer is over one of the collapsed messages in the review thread (e.g. "ojan RuntimeEnabledFeatures is exactly...").  Lift your fingers off the touchpad.

6. Press the physical left-click button (do NOT tap the touchpad) to expand the message.  Don't move the mouse pointer.

7. Start a new two-finger scroll drag from near the top of the touchpad.

In step 7, the scroll position immediately jumps to near the top of the page.

This bug is not specific to smooth scrolling, but there is some interaction with it.  When smooth scrolling is disabled, there is still a jump, but in a different direction (down instead of up).

Repros in stable (51.0.2704.63) and trunk build.

Comment 1 by, Jun 1 2016

 Issue 593389  has been merged into this issue.

Comment 2 by, Jun 1 2016

(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.)

Comment 3 by, Jun 1 2016

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.

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.
2.4 MB Download

Comment 4 by, Jun 3 2016

Labels: -Type-Bug -Pri-3 M-52 Pri-2 Type-Bug-Regression
Status: Assigned (was: Available)
Bisected locally down to this change:

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

Comment 5 by, Jun 3 2016

Labels: -M-52 M-51
Looks like that change was merged into 51.

Comment 6 by, Jun 3 2016

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.

Comment 7 by, Jun 12 2016

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.

Comment 8 by, Jun 13 2016

Mergedinto: 609748
Status: Duplicate (was: Assigned)

Comment 9 by, Jun 29 2016

Project Member
The following revision refers to this bug:

commit f7e731e7822967ab2d22530ea8d8487cf623ae3b
Author: w.shackleton <>
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 

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


Comment 10 by, Jun 29 2016

Labels: Merge-Request-52
Status: Started (was: Duplicate)
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)

Comment 11 by, Jun 30 2016

Labels: -Merge-Request-52 Merge-Approved-52 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M52 (branch: 2743)

Comment 12 by, Jun 30 2016

Labels: Needs-Feedback
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.

Comment 13 by, Jul 1 2016

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

Comment 14 by, Jul 1 2016

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).

Comment 15 by, Jul 1 2016

Project Member
Labels: -merge-approved-52 merge-merged-2743
The following revision refers to this bug:

commit f43fd606fed2ff91d4628a3f38ea2a0c83841644
Author: David Bokan <>
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 

Cr-Commit-Position: refs/heads/master@{#402966}
(cherry picked from commit f7e731e7822967ab2d22530ea8d8487cf623ae3b)

Review URL: .

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


Comment 16 by, Jul 1 2016

Status: Fixed (was: Started)
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).

Comment 17 by, Jul 1 2016

 Issue 609748  has been merged into this issue.

Comment 18 by, Jul 7 2016

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!

Comment 19 by, Jul 7 2016

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

Comment 20 by, Jul 7 2016

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.

Comment 21 by, Jul 7 2016

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.

Comment 22 by, Jul 14 2016

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

Comment 23 by, Jul 26 2016

Project Member
The following revision refers to this bug:

commit 5d5004de45d12a79de5dcd1a8e217dce3a1dc190
Author: w.shackleton <>
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

This CL also re-enables xinput2. I believe that all the bugs that caused it to
be disabled are now fixed (once 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

BUG= 616308 

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


Comment 24 by, Aug 4 2016

 Issue 630892  has been merged into this issue.

Comment 25 by, Sep 27 2016

Labels: Hotlist-Input-Dev

Sign in to add a comment