Issue metadata
Sign in to add a comment
|
|
||||||||||||||||||||||||
Issue descriptionI'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. , 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.) , Jun 1 2016Was 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.
, Jun 3 2016
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. , Jun 3 2016
Looks like that change was merged into 51. , Jun 3 2016How 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. , Jun 12 2016I 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. , Jun 13 2016
, Jun 29 2016Project MemberThe 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 , Jun 29 2016
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) , Jun 30 2016
Your change meets the bar and is auto-approved for M52 (branch: 2743) , Jun 30 2016
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. , Jul 1 2016Unfortunately, we don't have a canary channel on Linux and dev channel still hasn't caught up. , Jul 1 2016Chatted 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). , Jul 1 2016Project Member
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 , Jul 1 2016
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). , Jul 1 2016
Issue 609748 has been merged into this issue. , Jul 7 2016bokan@, 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! , Jul 7 2016Will do once Dev channel is pushed. My dev is still on 53.0.2783.2 and omahaproxy says as much. , Jul 7 2016Ok, 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. , Jul 7 2016FYI, 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. , Jul 14 2016This is in the latest M52 beta. I've confirmed the fix locally. , Jul 26 2016Project MemberThe 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 , Aug 4 2016Issue 630892 has been merged into this issue. , Sep 27 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by skobes@chromium.org, Jun 1 2016