1261576 - Scrollbar handle is not colored correctly when selected and dragged in gtk3

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Hussam Al-Tayeb]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160402102110

Steps to reproduce:

There is an issue with the scrollbars in gtk3 builds. Under adwaita, the gtk3 builtin default theme, the scrollbars are not colored blue when selected (only when hovered). The behavior in native gtk3 apps is blue colored selected scrollbars.

This also works in the gtk2 build so is a regression.

Comment 1

[Bill Gianopoulos [:WG9s]]

Actually they are blue when selected, but as soon as you slide it even a pixel the blue goes away.

Comment 2

[Bill Gianopoulos [:WG9s]]

OK.  Just to clarify further the difference between the old behavior and the behavior under Gtk3 with the pending patch for bug 1234158 applied.  With this patch applied under Gtk3, the scrollbar handle is light gray normally, dark gray when hovered and blue when selected (all of which are correct and agree with the old behavior)  What is wrong is that if you keep the scrollbar selected and drag it to actually scroll it reverts to the default light gray instead of remaining blue as expected.

Comment 3

[Bill Gianopoulos [:WG9s]]

One other issue i notices is that clicking and holding in the scrollbar outside the handle are should move the handle to that area and it should be clue as long as selected.  It is also light gray in that scenario, but that is probably the same sase as the other issue selected and moved.  I am also removing the regression keyword because I think have a regression keyword on a regression that cannot be seen without adding a wip patch is kind of lame.

Comment 4

[Hussam Al-Tayeb]

(In reply to Bill Gianopoulos [:WG9s] from comment #3)
> One other issue i notices is that clicking and holding in the scrollbar
> outside the handle are should move the handle to that area and it should be
> clue as long as selected.  It is also light gray in that scenario, but that
> is probably the same sase as the other issue selected and moved.  I am also
> removing the regression keyword because I think have a regression keyword on
> a regression that cannot be seen without adding a wip patch is kind of lame.

No need for patches. Just compile the current firefox release and link against gtk+ 3.18. The issue is there too.

Comment 5

[Bill Gianopoulos [:WG9s]]

(In reply to Hussam Al-Tayeb from comment #4)
> (In reply to Bill Gianopoulos [:WG9s] from comment #3)
> > One other issue i notices is that clicking and holding in the scrollbar
> > outside the handle are should move the handle to that area and it should be
> > clue as long as selected.  It is also light gray in that scenario, but that
> > is probably the same sase as the other issue selected and moved.  I am also
> > removing the regression keyword because I think have a regression keyword on
> > a regression that cannot be seen without adding a wip patch is kind of lame.
> 
> No need for patches. Just compile the current firefox release and link
> against gtk+ 3.18. The issue is there too.

Yes, I see that now.  I should not have been trying to go from memory.

Comment 6

[Michael Moravec]

I can confirm this on Gnome 3.20 with GTK+3 3.20 using Adwaita theme. Unfortunately I can't see the scrollbar when hovered/selected/dragged either...

Comment 7

[Bill Gianopoulos [:WG9s]]

(In reply to Michael Moravec from comment #6)
> Unfortunately I can't see the scrollbar when hovered/selected/dragged
> either...
THis is addresses by the pending patches for bug 1234158.

Comment 9

[John Felton]

Lubuntu 16.04 x64, GTK 3.18, Firefox 46.0. Same situation. Screencast attached.

Comment 10

[John Felton]

Attachment: gtk3-scrollbars-comparison.mp4

Comment 11

[Hussam Al-Tayeb]

Now that scrollbar themeing has landed, perhaps someone can take a look at this bug?
Thank you.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch

There's a simple fix for that. Need to check if we need that for pre-3.20 too.

Comment 13

[Hussam Al-Tayeb]

(In reply to Martin Stránský from comment #12)
> Created attachment 8765480 [details] [diff] [review]
> patch
> 
> There's a simple fix for that. Need to check if we need that for pre-3.20
> too.

This fixes it for me on gtk+ 3.20.6

Comment 14

[Bill Gianopoulos [:WG9s]]

(In reply to Martin Stránský from comment #12)
> Created attachment 8765480 [details] [diff] [review]
> patch
> 
> There's a simple fix for that. Need to check if we need that for pre-3.20
> too.

I can verify that this fixes the issue for me under both gtk 3.20 and gtk 3.18.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch

I'm unable to find exact commit but indicator_set_over() (from gtkscrolledwindow.c) which sets the "hovering" style to thumb was introduced in Gtk 3.16 so I guess it's safe to enable that for gtk3.16+.

Comment 16

[Bill Gianopoulos [:WG9s]]

I also verified that this compiles and does not seem to cause any issues if you build using the cairo-gtk2 toolkit.

Comment 17

[Karl Tomlinson (:karlt)]

(In reply to Martin Stránský from comment #15)
> I'm unable to find exact commit but indicator_set_over() (from
> gtkscrolledwindow.c) which sets the "hovering" style to thumb was introduced
> in Gtk 3.16 so I guess it's safe to enable that for gtk3.16+.

inHover corresponds to GTK_STATE_FLAG_PRELIGHT which I assume is the :prelight
(and :hover) pseudoclass.  The .hovering class from indicator_set_over() is different and for overlay scrollbars.

I assume this is the Adwaita rule involved:

    .scrollbar .slider:prelight:active {
      background-color: #2a76c6; }

The reason why gtkrange sets prelight as if in hover is that the mouse location is
set to the grab location when the pointer is grabbed during mouse down:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkrange.c?h=3.20.6#n3437

This is the same in older versions:

https://git.gnome.org/browse/gtk+/tree/gtk/gtkrange.c?h=3.4.4#n3349

I'm a little surprised that Gecko's scrollbar implementation is not similar.

Comment 18

[Karl Tomlinson (:karlt)]

Comment on attachment 8765824 [details] [diff] [review]
patch

>+              // Gtk 3.16+ also sets "hovering" state on active scrollbar thumb

Not this patch, because this bug is unrelated to 3.16 and "hovering" is a different concept.

Comment 19

[Karl Tomlinson (:karlt)]

Comment on attachment 8765480 [details] [diff] [review]
patch

But this patch is good, thanks, with the commit message from the other.

Comment 20

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch for check-in

Try:  https://treeherder.mozilla.org/#/jobs?repo=try&revision=a591ade2dbd3

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/265d5961e81a
render scrollbar thumb as "hovered" to emulate active Gtk thumb style. r=karlt

Comment 22

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/265d5961e81a