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

Issue 616308 link

Starred by 47 users

Issue metadata

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



Sign in to add a comment

Linux touchpad scroll jump

Project Member Reported by skobes@chromium.org, May 31 2016

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: https://codereview.chromium.org/1647793002

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.
 
Cc: w.shackl...@gmail.com skobes@chromium.org
 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.
scroll-jumping.webm
2.4 MB Download
Labels: -Type-Bug -Pri-3 M-52 Pri-2 Type-Bug-Regression
Owner: sadrul@chromium.org
Status: Assigned (was: Available)
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.
Labels: -M-52 M-51
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. 

Comment 8 by bokan@chromium.org, Jun 13 2016

Mergedinto: 609748
Status: Duplicate (was: Assigned)
Project Member

Comment 9 by bugdroid1@chromium.org, Jun 29 2016

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

Comment 10 by bokan@chromium.org, Jun 29 2016

Cc: sadrul@chromium.org
Labels: Merge-Request-52
Owner: bokan@chromium.org
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 dimu@google.com, 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)
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.
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).
Project Member

Comment 15 by bugdroid1@chromium.org, Jul 1 2016

Labels: -merge-approved-52 merge-merged-2743
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

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).
Cc: rnimmagadda@chromium.org smut@chromium.org brajkumar@chromium.org
 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.

Comment 22 by bokan@chromium.org, Jul 14 2016

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

Comment 23 by bugdroid1@chromium.org, Jul 26 2016

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.
Labels: Hotlist-Input-Dev

Sign in to add a comment