Open Bug 1197590 Opened 5 years ago Updated 4 years ago

middlemouse.scrollbarPosition no longer works on GTK3 scrollbars


(Core :: Widget: Gtk, defect, P3)





(Reporter: ke5trel, Unassigned)


(Blocks 1 open bug)


(Keywords: regression, Whiteboard: [gfx-noted][tpi:+])

Ubuntu 15.04

Steps to reproduce:

1. middlemouse.scrollbarPosition = true
2. Click the middle mouse button on a scrollable scrollbar.

Expected result:

Scrollbar should instantly jump to clicked position like with GTK2 scrollbars.

Actual result:

Nothing happens. 

It seems that left-clicking on the scrollbar now achieves the same result so this preference might be unnecessary.
Blocks: gtk3
Keywords: regression
It looks like this behavior is "intentional" at least in our code, as observed here:

GetScrollToClick() is internally checking the "gtk-primary-button-warps-slider" setting, which defaults to true. If this happens to be true, and hence as observed the primary button handles scroll-to-click, then the middle mouse button scroll-to-click gets disabled.

Karl, is this expected behavior? Did gtk2 not default this to true before?
Ever confirmed: true
Flags: needinfo?(karlt)
Whiteboard: [gfx-noted]
Looks like the default value may have changed in GTK+ 3.6.

Following the system behavior is intended for default pref values.

How that is meant to work with prefs is tricky when prefs don't have a use-system option.
Flags: needinfo?(karlt)
> It seems that left-clicking on the scrollbar now achieves the same result so this preference might be unnecessary.

actually that’s important for desktop integration.

all my applications jump with middle mouse, i want to be able to configure firefox to do the same, especially if it always had that pref. simply make the pref toggle that property and set it to whatever you want per default, but still let us change it
It took me a while to figure out how to fix the gtk setting. Create the file ~/.config/gtk-3.0/settings.ini if you don't already have one, and put this in it:

gtk-primary-button-warps-slider = false
See Also: → 1268784
Duplicate of this bug: 1268784
Thanks to Jim Rees for a usable workaround!  Also agree that this should be handled internally within Firefox by honoring middlemouse.scrollbarPosition.
Firefox 46.0
Xubuntu 15.10

Another issue that I notice that may be related to GTK+ is that cut and paste withing Firefox has become very unreliable.  I have a dual desktop system with two versions (two different profiles) running on each.  The above workaround by Jim Reese has been implemented.  The usual Linux ability to select text using B1 and then past it elsewhere using B2 works between apps on either screen, but does not work between a selection made on one screen and the Firefox instance running on the other.


1: I B1 select text in an xterm and can B2 paste it into another another xterm or into the URL bar on Firefox running on either screen.

2: I B1 select text from the Firefox URL bar and can B2 paste it into another app (xterm for example) on the same screen, but cannot paste it into any app, including Firefox, on the other screen.

So B1/B2 copy/paste are working system-wide as expected, but Firefox is doing something strange with its own selections that do not conform to expected behavior.
Blocks: 803633
Duplicate of this bug: 1277469
Priority: -- → P3
Whiteboard: [gfx-noted] → [gfx-noted][tpi:+]
Yes, thank-you for the work-around.  I'm not sure if my criticism should be against firefox or gtk, but if a left mouse click causes the view to jump to that location, how is the user supposed to page down or up with the mouse?
Duplicate of this bug: 1343297
You need to log in before you can comment on or make changes to this bug.