GNOME Bugzilla – Bug 721047
Clicking on a scroll bar results in useless and unpredictable behaviour
Last modified: 2015-08-10 15:47:25 UTC
When I have a page with a lot of content (in my example the credits in the about box) there is no way to move up or down a page. My only options are: 1) Use the mouse wheel, which is very slow 2) Click somewhere below or above the slider, which results in the content jumping to that point. As opposed to what it used to do, and still does on every other platform I know including GTK2: go up or down one page at a time. I've googled this for a while and found that apparently the old behaviour can be restored using gtk-primary-button-warps-slider = false in ~/.config/gtk-3.0/settings.ini I was finishing up migrating one of my projects (Asunder) from GTK2 to GTK3 when I found this bug, which is significant enough that I'm going to roll back to GTK2. Also as a user I find this extremely annoying in the programs that were ported to GTK3: specifically evince and synaptic come to mind. Clicking on the scrollbar results in the content view jumping to some completely undefined location in the document. It is pretty much impossible to guess what you're going to get or how to return to the previous location in the document. I looked at these documents: https://wiki.gnome.org/Design/OS/Scrolling https://wiki.ubuntu.com/Ayatana/ScrollBars And this behaviour is not even in the designs. A mouse-controlled scrollbar is the only type affected by this "feature" and in this environment it doesn't work as expected, so as far as I know this change has been introduced accidentally without thinking it through.
Sorry guys, I know this is open source and noone working on GTK owes anyone a damned thing, but seriously, is this just going to be ignored?
It is a known issue; and is not forgotten.
Will the behavior be reverted back to gtk2 style scrolling as the default?
Is there any way to bump the priority on this? This is a really frustrating bug and affects a lot of apps under Linux.
(In reply to Tushar T from comment #3) > Will the behavior be reverted back to gtk2 style scrolling as the default? It is not planned, no. (In reply to josh.sarro from comment #4) > Is there any way to bump the priority on this? This is a really frustrating > bug and affects a lot of apps under Linux. You can change your configuration. Scrolling is continuously worked on; we have further changes in the pipeline for 3.18, which should improve paging. You can also modify the theme to re-introduce steppers, by adding: .scrollbar { -GtkScrollbar-has-forward-stepper: true; -GtkScrollbar-has-secondary-backward-stepper: true; } to the ~/.config/gtk-3.0/settings.ini file.
(In reply to Emmanuele Bassi (:ebassi) from comment #5) > (In reply to Tushar T from comment #3) > > Will the behavior be reverted back to gtk2 style scrolling as the default? > > It is not planned, no. In the light of this answer (which I agree with), I would suggest to close this bug. We don't agree with the complaint ("useless, unpredicatable behavior"), we don't plan to implement the change that is suggested here ("revert to gtk2 scrolling"), and there is an option to get the desired outcome anyway.
Given that it's not getting fixed a WONTFIX seems appropriate, but I wouldn't characterize it as INVALID unless you can explain how that's supposed to make sense to the user. It's bad to the point that I can't name a single application that uses the default behaviour on Linux Mint, which is why I kind of forgot about this bug.
Some justifications would certainly be warranted here before resolving as "won't fix". The GTK-3 scrollbar works in a way that is very different than every other scrollbar past and present. This is jarring for a user who is used to a particular way of using the scrollbar and who is switching back and forth between other applications with scrollbars. That in itself might not be enough to discourage a change, however, it seems to me that any change that would deviate the expected behavior of such an ubiquitous and useful part of the GUI should have a major advantage to justify the change. As mentioned above, it is unclear what advantage the new behavior offers. Jumping to a random page in a large document seems much less useful than going up or down a page at a time. And therefore it would make more sense to have the new behavior set to use right click by default, so that normal users aren't confused by it, and advanced users can make use of it as needed. But if the new behavior must stick around as a default, it would at least be nice if the settings for it were more easily accessible to change. A user shouldn't have to edit an obscure file to get normal scrollbar behavior back. I've been looking for a solution to this for a couple of years now!
(In reply to josh.sarro from comment #8) ... > But if the new behavior must stick around as a default, it would at least be > nice if the settings for it were more easily accessible to change. A user > shouldn't have to edit an obscure file to get normal scrollbar behavior > back. I've been looking for a solution to this for a couple of years now! It seems nobody noted down a reference to bug 704277 in this bug. I agree with your comment on the need of a way to change the behavior but the solutions was not so much hidden. Just a search away in this same bugzilla. Would be nice if someone can add 704277 in the "See also" field of this bug. I cannot do that.