GNOME Bugzilla – Bug 788905
GtkRange horizontal scrolling causes movement in the wrong direction
Last modified: 2017-10-23 13:44:05 UTC
I'm getting this bizarre, totally broken behaviour with GTK+ 3.22.24, x11, and libinput10_1.8.3-1_amd64.deb. juliank in #debian-gnome confirmed the problem, though I didn't yet hear back as to which backend/input library he was using. I didn't try switching to Wayland or synclient yet, but then I shouldn't have to... Peetz0r in GNOME confirmed it with horizontal scrolling on a trackpad: > Peetz0r dboles: yep, the horizontal scales scroll inverted using trackpoint scrolling on my thinkpad > Peetz0r wayland, libinput, gnome 3.24, fedora 26, thinkpad yoga 370 Put simply: scrolling horizontally (here, with a touchpad and 2 fingers) on the trough of any GtkRange causes its slider/value to move in the opposite direction from what I scroll. For example, check the horizontal Scales in widget-factory. Natural scrolling is disabled. Vertical scrolling works as expected in all cases. xev shows the correct button numbers (6 for left, 7 for right). Toggling on natural scrolling in g-c-c 'fixes' the horizontal case, but obviously not really, because now vertical ranges behave the opposite way of what I want... Scrolling horizontally on the content area of a ScrolledWindow goes in the right direction, but obviously that's implemented differently, so it hardly matters. maybe an issue in libinput, but hard to grasp how, since e.g. the ScrolledWindow body and other applications work OK. So this may be specific to GtkRanges.
My reproduction was on Wayland (so also libinput).
For some weird reason, vertical scrolling in gnome-control-center's sound level widget also scrolls the wrong way around (but screen brightness in power works the right way around...).
lmao, gnome-shell's volume and brightness sliders scroll towards 0, regardless of whether they're scrolled left or right
output from xinput --list-props: Device 'AlpsPS/2 ALPS GlidePoint': Device Enabled (141): 1 Coordinate Transformation Matrix (143): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (278): 1 libinput Tapping Enabled Default (279): 0 libinput Tapping Drag Enabled (280): 1 libinput Tapping Drag Enabled Default (281): 1 libinput Tapping Drag Lock Enabled (282): 0 libinput Tapping Drag Lock Enabled Default (283): 0 libinput Tapping Button Mapping Enabled (284): 1, 0 libinput Tapping Button Mapping Default (285): 1, 0 libinput Natural Scrolling Enabled (286): 0 libinput Natural Scrolling Enabled Default (287): 0 libinput Left Handed Enabled (288): 0 libinput Left Handed Enabled Default (289): 0 libinput Accel Speed (290): 0.088235 libinput Accel Speed Default (291): 0.000000 libinput Scroll Methods Available (292): 1, 1, 0 libinput Scroll Method Enabled (293): 1, 0, 0 libinput Scroll Method Enabled Default (294): 1, 0, 0 libinput Middle Emulation Enabled (295): 1 libinput Middle Emulation Enabled Default (296): 1 libinput Send Events Modes Available (263): 1, 1 libinput Send Events Mode Enabled (264): 0, 0 libinput Send Events Mode Enabled Default (265): 0, 0 libinput Disable While Typing Enabled (297): 1 libinput Disable While Typing Enabled Default (298): 1 Device Node (266): "/dev/input/event1" Device Product ID (267): 2, 8 libinput Drag Lock Buttons (299): <no items> libinput Horizontal Scroll Enabled (300): 1
(In reply to Julian Andres Klode from comment #2) > For some weird reason, vertical scrolling in gnome-control-center's sound > level widget also scrolls the wrong way around I couldn't seem to reproduce this. I can't see anything immediately wrong with the GtkRange code, but I've only glanced over it; I'd need to do some debugging/annotation later to get a better idea of what's going so wrong here.
Just FWIW, this is a side effect of natural scrolling. No matter how we do it, we will always move ranges in the wrong direction with one of the two options. During guadec, wayland protocol changes to convey applications the physical direction of the scroll event was devised, but it did not progress further after that. https://lists.freedesktop.org/archives/wayland-devel/2017-August/034711.html (In reply to Daniel Boles from comment #3) > lmao, gnome-shell's volume and brightness sliders scroll towards 0, > regardless of whether they're scrolled left or right AFAICS gnome-shell sliders only listen to scroll up/down. You were probably scrolling diagonally towards the same upper/lower side when scrolling left and right.
(In reply to Carlos Garnacho from comment #6) > Just FWIW, this is a side effect of natural scrolling. No matter how we do > it, we will always move ranges in the wrong direction with one of the two > options. Yiiikes. I hadn't realised natural scrolling impacted the horizontal axis. Even then, I might've expected that having it enabled would invert horizontal scrolling - but not when it's disabled.
from IRC: > [garnacho] dboles: natural scrolling is basically multiplying scroll's dx/dy by -1. I meant that whenever we make it behave right with natural-scroll toggled on or off, we are making the other value work "backwards" with GtkRange > > [dboles] right, but how does making normal ('unnatural'?) vertical scrolling work, mean that horizontal scrolling has to be inverted (and hence now acts natural) > > [garnacho] dboles: the usual assumption is up=left when translating v/h scroll > but up is down and left is right with natural scroll > dboles: the idea of that protocol is that we can know whether natural scroll was applied to scroll dx/dy, so we can honor it on scrolled windows, and ignore it in ranges > > [dboles] why can't GtkRange do whatever GtkScrolledWindow does, which works as expected regardless of the natural scrolling setting? > sorry, i just have trouble wrapping my head around this > i.e. in a ScrolledWindow, scrolling left when natural scrolling is off == the content scrolls left > scrolling left when natural scrolling is on == the content scrolls right > > [garnacho] dboles: the principle that makes natural scrolling look "natural" is that you "drag the content", but ranges have no content, you want left to be left and up to be up when dragging the slider > > [dboles] garnacho: but the wrong horizontal scrolling on GtkRange happens when natural scrolling is off, so how will ignoring it help? :S > > [garnacho] dboles: right, probably the up=left assumption was broken somewhere, and probably in confusion to cater for natural scroll :) > dboles: will have a look at it :) > anyhow, looking forward to have that protocol bit in place
Created attachment 361588 [details] [review] Range: Fix inverted horizontal scroll wheel events Bug 737175 aimed to ensure that scrolling up on a horizontal range would result in its value increasing, as that’s what users intuitively expect. However, its commit 416c370da1d2eff2458e4a0c5b8e504cd8061559 meant that, if the event gives scroll deltas, we inverted our delta unconditionally. So it broke horizontal scrolling: scrolling left moved the slider right… We must only invert if using dy as delta. dx already has the right sign, so inverting it was wrong.
Attachment 361588 [details] pushed as 9106436 - Range: Fix inverted horizontal scroll wheel events This seems obviously correct.
This: (In reply to Carlos Garnacho from comment #6) > Just FWIW, this is a side effect of natural scrolling. No matter how we do > it, we will always move ranges in the wrong direction with one of the two > options. > > During guadec, wayland protocol changes to convey applications the physical > direction of the scroll event was devised, but it did not progress further > after that. > > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034711.html wasn't directly related, but it did remind me of Bug 739806, which will presumably be fixed as a consequence.
*** Bug 788824 has been marked as a duplicate of this bug. ***