1

In Debian 10, but since older versions (always using Gnome), the scrollbar usually follows the mouse (the scrollbar knob is always below the cursor), but sometimes it scrolls the page contents much slower (the knob lags behind the cursor - e.g. the cursor have "walked" 500 pixels, but the knob only "walked" 50 pixels).

Not a Gnome image, but you got the idea of what I'm calling "scrollbar knob":

scrollbar "knob"

Most of the time I get the first behavior. Rarely, and unpredictably, I get the second.

Actually I'm more used to see it happening on vertical scrollbars, but I guess it may happen equally on horizontal. And it usually happens when the content is much larger than the window, so that the knob is actually much smaller than on the image.

After five years using Debian+Gnome, I still can't figure what causes the difference. Can anybody explain it? I didn't find anything on Google (maybe I don't know the right words to search?).

4
  • are you talking about a horizontal scrollbar? .... maybe the difference is in the width of the window relative to the width of the view .... for example, if web browser app is 800 pixels wide, but the window is set to 400 pixels, so the scroll bar has to move a lot to display the hidden parts .... if the window is set to 600 pixels wide, then the scroll bar does not have to move as much – jsotola Apr 9 '20 at 6:01
  • @jsotola Actually I'm more used to see it on vertical scrollbars, but I guess there's no difference. And it usually happens when the content is much larger than the window, so that the knob is actually much smaller than on the image. I edited the question accordingly. – Rodrigo Apr 9 '20 at 6:18
  • Is it same with all GTK/QT themes? – BlueManCZ Apr 9 '20 at 9:44
  • It sounds like there's thresholds for the width and height of the page that causes it to switch the behavior of the scrollbar, to keep it from becoming too sensitive to mouse movements. For small pages, it's fine to scroll the full height or width when you move the mouse from one side of the screen to the other. But for a large page, that would cause even small mouse movements to zip through a good chunk of page, so then it's better to have the page scroll at some fraction of the rate of mouse movement. – Roger Dahl Feb 6 at 3:07
3

It's a feature from GTK's scrollbar, called smooth scrolling, which allows the user to slow the scroll speed, allowing a pixel-precise positioning.

The scroll enters this mode when you scroll pressing the Shift key or if you long-press the slider before moving it, which is probably your case.

Unfortunately, currently there isn't any setting in GTK that allows us to disable or modify this default behaviour.

4
  • Exactly! Same "problem" and found same reason. S.o. needs to file a feature request for a setting to configuren this. There should be s.th. like pressing right mouse button and scroll then. It always bothers me, if i stopped scrolling while still pushing the mouse button and then continuing in slow motion. I dont expect it to be how it currently works. Its unnatural. – WGRM Apr 9 '20 at 11:58
  • Strangely, neither shift nor long-press are doing it here now. Tried on that site, which has a long content compared to screen height. – Rodrigo Apr 9 '20 at 15:36
  • Right, it's not working on Firefox, but worked nice on Terminal. Thank you! – Rodrigo Apr 10 '20 at 6:05
  • Check on Firefox :config if the gtk-related flags are enabled – Dani Garcia Apr 10 '20 at 7:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.