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 722438 - Scrolling: be able to disable the zoom/precise mode
Scrolling: be able to disable the zoom/precise mode
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkRange
3.18.x
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-01-17 18:10 UTC by Sébastien Wilmet
Modified: 2018-05-02 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sébastien Wilmet 2014-01-17 18:10:22 UTC
I don't like the scrolling zoom mode, it is not how I use the scrollbar.

When I want to skim through the content to find quickly what I'm searching, I do that in several steps:

1. click on the scrollbar, and hold the button pressed.
2. look at the content, perhaps reading the section titles.
3. scroll to find the section I want to read.

The problem: during step 2, the scrollbar often goes into zoom mode, so step 3 doesn't work.

The workaround is to directly move the scrollbar just after we click on it, so the zoom mode is disabled. But this is not convenient.

And for me the zoom mode is useless, if I need to scroll a small distance, I use the mouse scroll wheel.

I think the zoom mode is not a good idea. It should at least be possible to disable it.
Comment 1 haarp 2014-06-15 15:32:36 UTC
I agree. This behavior should really be toggleable, just like gtk-primary-button-warps-slider is. Zoom mode is extremely unintuitive for me and constantly gets in the way of what I'm trying to do.
Comment 2 Thomas Raffler 2014-06-20 15:12:26 UTC
I have to support this bug report being a gtk user since 10 years. It took me a long time to finally find the cause of this behaviour. 
I was blaming ubuntu first (overlay remainings) and later searched the web for keywords like scrollbar, gtk, slow, weird, bug. Now I know it's a feature. 

My suggestion:
1. Remove the time-triggered zooming feature.
2. Make the new zoom-mode the default for right-click action

There are maybe not many supporters here, but most normal users will not find this bug report...
Comment 3 Garrett Regier 2014-09-25 23:01:45 UTC

*** This bug has been marked as a duplicate of bug 728739 ***
Comment 4 Sébastien Wilmet 2014-10-22 14:19:42 UTC
I move this bug to gnome-tweak-tool, since the GTK+ devs don't care.

There is a workaround described there:
https://bugzilla.gnome.org/show_bug.cgi?id=728739#c9

It would be nice to have a setting directly in gnome-tweak-tool for that.
Comment 5 Thomas Glyn Dennis 2014-11-02 15:02:03 UTC
Hi,

I've created a small Tk/Python script that allows this setting to be changed via a simple GUI: https://gitorious.org/gtk-scrollfix/gtk-scrollfix

Hopefully some people might find this useful until the gnome-tweak-tool adds support for it.
Comment 6 Matthias Clasen 2014-11-03 02:15:58 UTC
(In reply to comment #4)
> I move this bug to gnome-tweak-tool, since the GTK+ devs don't care.

It is not true that GTK+ developers don't care. There's 3000 open GTK+ bugs, and not all of them are easy.
 
> There is a workaround described there:
> https://bugzilla.gnome.org/show_bug.cgi?id=728739#c9
> 
> It would be nice to have a setting directly in gnome-tweak-tool for that.

This 'workaround' affects not just the scrolling zoom mode, but every use of long presses in GTK+.
Comment 7 John Baptist 2015-04-19 17:14:01 UTC
I agree that there needs to be a way to disable the zoom mode of scrolling. I often unintentionally trigger zoom mode when viewing the scrollback in a terminal when I get a long stack trace, with the results that I can't view the whole thing without re-clicking and losing my place. Very annoying.
Comment 8 sworddragon2 2015-05-04 10:13:53 UTC
(In reply to Sébastien Wilmet from comment #0)
> The workaround is to directly move the scrollbar just after we click on it,
> so the zoom mode is disabled. But this is not convenient.

This does only disable the zoom mode if the scrollbar gets moved far enough. If it gets moved only a few pixel the zoom mode can still trigger. But I'm not sure if this is a bug or a feature.


(In reply to Sébastien Wilmet from comment #4)
> I move this bug to gnome-tweak-tool, since the GTK+ devs don't care.

If this issue is more related to GTK+ than gnome-tweak-tool I recommend to change the product back to gtk+ as otherwise it could delay a potential fix even more.


Also I'm affected by this issue if I'm programming something which hits productivity a bit. Personally I would like an option to en/disable this feature too but I also think that the zoom mode needs a better mechanism to trigger as it could be a really useful feature.
Comment 9 Sébastien Wilmet 2015-10-30 10:58:34 UTC
Re-assigning back to GTK+.
Comment 10 Matthijs Kooijman 2015-12-03 07:45:19 UTC
I also ran into the problem of triggering scrolling zoom mode unintentionally. I use a pen tablet instead of a mouse, so lacking a scrollwheel I'm dependent on dragging the scrollbar for all my scrolling. One would say that zoom mode would help here, but in practice it only hinders my scrolling when I want to slow scroll through a file to read it.

At least having a gtk setting for disabling zoom mode would be good, even if there is no GUI for setting it?
Comment 11 burritobazooka+gnome 2016-10-19 02:45:32 UTC
Is there a place to file more "systematic" bugs like user feedback not being taken into account?
Comment 12 burritobazooka+gnome 2016-10-19 02:50:43 UTC
30 USD for whoever fixes this. Copy and paste the issue URL into Bountysource's search.
Comment 13 Tony Houghton 2016-10-19 12:49:59 UTC
For me it's now triggered by pressing shift at the start of a drag instead of by a long press, but I haven't noticed this issue for a long time (since the delay was made longer some time ago). I'm using 3.22 in Debian, but I can't find a relevant entry in either the Debian or upstream changelog.

Shift seems like a more usable trigger to me, but it does have its own problems for any ambitions about running GTK on phones etc.
Comment 14 burritobazooka+gnome 2016-10-19 17:02:29 UTC
Trying to make things like this universal among different physical platforms has been tried (by Microsoft) and it didn't work out too well.

In my own case, increasing gtk-long-press-time in ~/.config/gtk-3.0/settings.ini to 4000 disables the feature completely, not sure how. No matter how long I hold it in for (way over 4 seconds), it doesn't budge. I don't know what other programs or widgets use the long-press feature, so I don't know whether it breaks anything else.

However, I can still use it if I press shift and then click. That's satisfactory, and if more apps used GTK-greater-than-2 (whatever the correct terminology is now), I would probably use it sometimes (like scrolling through long terminal output). It seems I'm also using Debian's libgtk-3-0 version 3.22.1-1.
Comment 15 Tony Houghton 2016-10-19 17:15:49 UTC
(In reply to burritobazooka+gnome from comment #14)

> In my own case, increasing gtk-long-press-time in
> ~/.config/gtk-3.0/settings.ini to 4000 disables the feature completely, not
> sure how.

Oops, I completely forgot I'd done that too, except in my case it's 3000. This seems to be about 6s, so it appears that the units are 2ms instead of 1ms. So maybe not disabled in your case, just much longer than you thought?
Comment 16 burritobazooka+gnome 2016-10-19 19:02:02 UTC
(In reply to Tony Houghton from comment #15)
> 
> Oops, I completely forgot I'd done that too, except in my case it's 3000.
> This seems to be about 6s, so it appears that the units are 2ms instead of
> 1ms. So maybe not disabled in your case, just much longer than you thought?

Yep, that's indeed what happened. How unintuitive.
Comment 17 sworddragon2 2016-10-19 22:29:22 UTC
Eventually the 2ms per unit is just another bug and needs to be reported.
Comment 18 sworddragon2 2016-10-19 22:50:59 UTC
Edit: On thinking about it maybe gtk-long-press-time can be enhanced for an unlimited time as a simple way to disable this feature (for example with the value -1) so users can still rely on using shift to explicitly enable this feature if they want.
Comment 19 burritobazooka+gnome 2016-10-19 23:02:40 UTC
As stated previously in this thread, setting gtk-long-press-time is a non-solution to this bug as it would also affect every other widget which long-press (though I don't know of any that I have actually used). All we need is an option like gtk-enable-zoom-scroll and/or gtk-enable-auto-scroll
Comment 20 sworddragon2 2016-10-19 23:20:41 UTC
In that case maybe the suggested option to disable this feature should not disable it if the user explicitly enables it with shift.
Comment 21 Daniel Boles 2017-09-11 11:03:52 UTC
The zoom/fine-tune behaviour comes from GtkRange, and even if this could be grafted onto Scroll(bar|edWindow) only, inevitably people would want it for GtkScale et al too, so moving.


(In reply to burritobazooka+gnome from comment #11)
> Is there a place to file more "systematic" bugs like user feedback not being
> taken into account?

Please, start by not assuming bad intentions everywhere... User feedback is great, but resources aren't infinite, and again:

(In reply to Matthias Clasen from comment #6)
> (In reply to comment #4)
> > I move this bug to gnome-tweak-tool, since the GTK+ devs don't care.
> 
> It is not true that GTK+ developers don't care. There's 3000 open GTK+ bugs,
> and not all of them are easy.
Comment 22 GNOME Infrastructure Team 2018-05-02 15:55:18 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/462.