Closed Bug 1261576 Opened 9 years ago Closed 8 years ago

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

Categories

(Core :: Widget: Gtk, defect)

48 Branch
All
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
firefox50 --- fixed

People

(Reporter: ht990332, Unassigned)

References

Details

Attachments

(3 files, 1 obsolete file)

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.
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Linux
Hardware: Unspecified → All
Actually they are blue when selected, but as soon as you slide it even a pixel the blue goes away.
Depends on: 1234158
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.
Summary: Scrollbar is not colored correctly when selected in gtk3 → Scrollbar is not colored correctly when selected and dragged in gtk3
Summary: Scrollbar is not colored correctly when selected and dragged in gtk3 → Scrollbar handle is not colored correctly when selected and dragged in gtk3
Blocks: 1234158
No longer depends on: 1234158
Keywords: regression
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.
Keywords: regression
(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.
(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.
Blocks: gtk3
No longer blocks: 1234158
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...
(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.
Lubuntu 16.04 x64, GTK 3.18, Firefox 46.0. Same situation. Screencast attached.
Attached video gtk3-scrollbars-comparison.mp4 (deleted) —
Now that scrollbar themeing has landed, perhaps someone can take a look at this bug? Thank you.
Attached patch patch (deleted) — Splinter Review
There's a simple fix for that. Need to check if we need that for pre-3.20 too.
(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
(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.
Attached patch patch (obsolete) (deleted) — Splinter Review
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+.
Attachment #8765480 - Attachment is obsolete: true
Attachment #8765824 - Flags: review?(karlt)
I also verified that this compiles and does not seem to cause any issues if you build using the cairo-gtk2 toolkit.
(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 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.
Attachment #8765824 - Flags: review?(karlt) → review-
Comment on attachment 8765480 [details] [diff] [review] patch But this patch is good, thanks, with the commit message from the other.
Attachment #8765480 - Attachment is obsolete: false
Attachment #8765480 - Flags: review+
Attachment #8765824 - Attachment is obsolete: true
Pushed by cbook@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/265d5961e81a render scrollbar thumb as "hovered" to emulate active Gtk thumb style. r=karlt
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: