After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788905 - GtkRange horizontal scrolling causes movement in the wrong direction
GtkRange horizontal scrolling causes movement in the wrong direction
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkRange
3.22.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
: 788824 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-10-12 22:02 UTC by Daniel Boles
Modified: 2017-10-23 13:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Range: Fix inverted horizontal scroll wheel events (1.34 KB, patch)
2017-10-14 17:48 UTC, Daniel Boles
committed Details | Review

Description Daniel Boles 2017-10-12 22:02:53 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.
Comment 1 Julian Andres Klode 2017-10-12 22:06:37 UTC
My reproduction was on Wayland (so also libinput).
Comment 2 Julian Andres Klode 2017-10-12 22:10:07 UTC
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...).
Comment 3 Daniel Boles 2017-10-12 22:12:44 UTC
lmao, gnome-shell's volume and brightness sliders scroll towards 0, regardless of whether they're scrolled left or right
Comment 4 Daniel Boles 2017-10-12 22:29:42 UTC
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
Comment 5 Daniel Boles 2017-10-13 09:08:35 UTC
(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.
Comment 6 Carlos Garnacho 2017-10-13 09:34:07 UTC
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.
Comment 7 Daniel Boles 2017-10-13 09:57:06 UTC
(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.
Comment 8 Daniel Boles 2017-10-14 14:02:27 UTC
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
Comment 9 Daniel Boles 2017-10-14 17:48:55 UTC
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.
Comment 10 Daniel Boles 2017-10-14 17:59:40 UTC
Attachment 361588 [details] pushed as 9106436 - Range: Fix inverted horizontal scroll wheel events


This seems obviously correct.
Comment 11 Daniel Boles 2017-10-14 22:14:53 UTC
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.
Comment 12 ZenWalker 2017-10-23 13:44:05 UTC
*** Bug 788824 has been marked as a duplicate of this bug. ***