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)
Tracking
()
RESOLVED
FIXED
mozilla50
Tracking | Status | |
---|---|---|
firefox50 | --- | fixed |
People
(Reporter: ht990332, Unassigned)
References
Details
Attachments
(3 files, 1 obsolete file)
(deleted),
video/mp4
|
Details | |
(deleted),
patch
|
karlt
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•9 years ago
|
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Updated•9 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Linux
Hardware: Unspecified → All
Comment 1•9 years ago
|
||
Actually they are blue when selected, but as soon as you slide it even a pixel the blue goes away.
Comment 2•9 years ago
|
||
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.
Updated•9 years ago
|
Summary: Scrollbar is not colored correctly when selected in gtk3 → Scrollbar is not colored correctly when selected and dragged in gtk3
Updated•9 years ago
|
Summary: Scrollbar is not colored correctly when selected and dragged in gtk3 → Scrollbar handle is not colored correctly when selected and dragged in gtk3
Updated•9 years ago
|
Comment 3•9 years ago
|
||
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
Reporter | ||
Comment 4•9 years ago
|
||
(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•9 years ago
|
||
(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.
Updated•9 years ago
|
Comment 6•9 years ago
|
||
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•9 years ago
|
||
(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•9 years ago
|
||
Lubuntu 16.04 x64, GTK 3.18, Firefox 46.0. Same situation. Screencast attached.
Comment 10•9 years ago
|
||
Reporter | ||
Comment 11•8 years ago
|
||
Now that scrollbar themeing has landed, perhaps someone can take a look at this bug?
Thank you.
Comment 12•8 years ago
|
||
There's a simple fix for that. Need to check if we need that for pre-3.20 too.
Reporter | ||
Comment 13•8 years ago
|
||
(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•8 years ago
|
||
(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•8 years ago
|
||
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)
Comment 16•8 years ago
|
||
I also verified that this compiles and does not seem to cause any issues if you build using the cairo-gtk2 toolkit.
Comment 17•8 years ago
|
||
(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•8 years ago
|
||
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 19•8 years ago
|
||
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+
Updated•8 years ago
|
Attachment #8765824 -
Attachment is obsolete: true
Comment 20•8 years ago
|
||
Updated•8 years ago
|
Keywords: checkin-needed
Comment 21•8 years ago
|
||
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
Comment 22•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox50:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in
before you can comment on or make changes to this bug.
Description
•