scroll bar behavior has changed in GTK




3 years ago
3 years ago


(Reporter: George R. Goffe, Unassigned)


40 Branch

Firefox Tracking Flags

(Not tracked)




3 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150730171029

Steps to reproduce:

I'm running a beta FF at 40.0 and have noticed that the scroll bars behavior has changed for several weeks now.

Actual results:

I used to use clicks above/below the "current" line in a URL to scroll forward/backward by one page. Now, the current line becomes wherever I have clicked within the scroll bar. This is awkward to use and makes navigation more difficult. This behavior ought to be selectable if it is intended that the feature/change will remain.

Expected results:

see description above.
To be clear: you are saying that if you load a long page, and then click at the very bottom of the scrollbar on the right side of the page, the page jumps to the very bottom of the article rather than doing a single "Page Down"?

I can't reproduce this behaviour in Firefox 41.0a2 (Aurora; Developer Edition) on Ubuntu Linux 14.04 LTS. 

Can you go to Help | Troubleshooting Information, click "Restart with Addons Disabled" and then try again? Obviously, make sure you test with a page long enough to tell the difference... :-)

The other option is that your shift key is stuck, because shift-click has the behaviour you describe. If you are still seeing it without shift, what does holding shift do?


Comment 2

3 years ago

I have tried your shift+click idea, this exhibits the old behavior. The only problem I have now is that I need to use BOTH hands to do this. Is there an option to reverse the keystrokes in Firefox?

Can you tell me about how changes to the UI happen? Is there oversight on them? Is there an approval cycle involved? Is there a write up whenever the UI changes like this?

Regards, and thanks for your help,

I don't think there's been a change, that's my point. Did you try restarting with addons disabled, as suggested?


Comment 4

3 years ago

There was no change with plugins disabled.

This is the only application that behaves this way so I'm tending to believe that it's NOT KDE. They DO allow for a lot of keymap changes but I could not find ANY "Shift+Click" settings.

Is there a way to reverse the mapping in FF? I would just reverse the setting.


It would be helpful if you could produce a regression range for this using mozregression:

That might help us isolate what happened here.
Component: Untriaged → General
OS: Unspecified → Linux
Hardware: Unspecified → All

Comment 6

3 years ago

I tried to play the video for moz regression but there was no sound. Sigh... I went back to the latest release and the sound does work. I'm using the flash-plugin from Adobe (flash-plugin-

Your thoughts?

George: you don't need to watch the video; you could just read the instructions. But if you find some way of getting it working, just watch it - let's fix one problem at once.

If you get the video working, you only need to watch from 1:27 onwards.


Comment 8

3 years ago
Apparently we use the system setting for this (gtk-primary-button-warps-slider) since Firefox 34, which is often the unwanted click-to-scroll-immediately (bug 803633 comment 40). Workaround: - set to 0.

FWIW, I can reproduce using's nightly, but not using the version that came with Ubuntu.

I guess you should figure out what the value of that setting is on your system. Until you find that it's not instructing Firefox to behave this way, there doesn't seem to be a problem here that can be fixed on the Firefox side.
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
Summary: scroll bar behavior has changed → scroll bar behavior has changed in GTK

Comment 9

3 years ago

I added "Ui.scrollToClick" as an integer in about:config for FF Nightly... It seems to have taken effect immediately.


You need to log in before you can comment on or make changes to this bug.