Hovered preferences headers should keep text color

RESOLVED WORKSFORME

Status

()

Toolkit
Themes
RESOLVED WORKSFORME
10 years ago
2 years ago

People

(Reporter: Takeshi Kurosawa, Assigned: Takeshi Kurosawa)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

10 years ago
Created attachment 304417 [details] [diff] [review]
Patch

Hovered preferences/pageinfo/addons headers inherit global |radio:hover| rule (|color: -moz-buttonhovertext|). When |-moz-buttonhovertext| is different from the default color, hovered headers changes its text color.

We should keep the header color when it's hovered.
Attachment #304417 - Flags: review?(ventnor.bugzilla)
(Assignee)

Comment 1

10 years ago
Created attachment 304419 [details]
Screenshot shows the problem (Highcontrast inverse theme)
Please request review from rflint@mozilla.com.
Component: OS Integration → Theme
QA Contact: os.integration → theme
(Assignee)

Comment 3

10 years ago
Comment on attachment 304417 [details] [diff] [review]
Patch

reed, thanks your comment :-)
Attachment #304417 - Flags: review?(ventnor.bugzilla) → review?(rflint)

Comment 4

10 years ago
Aren't there just CSS rules you could remove somewhere that makes this change in the first place?
Component: Theme → OS Integration
(Assignee)

Comment 5

10 years ago
(In reply to comment #4)
> Aren't there just CSS rules you could remove somewhere that makes this change
> in the first place?
> 

global |radio:hover| rule is needed for regular radio widget.

http://mxr.mozilla.org/seamonkey/source/toolkit/themes/gnomestripe/global/radio.css#128

Comment 6

10 years ago
(In reply to comment #5)
> (In reply to comment #4)
> > Aren't there just CSS rules you could remove somewhere that makes this change
> > in the first place?
> > 
> 
> global |radio:hover| rule is needed for regular radio widget.
> 
> http://mxr.mozilla.org/seamonkey/source/toolkit/themes/gnomestripe/global/radio.css#128
> 

Is that even used by normal radiobuttons? To me it looks like something you can remove.
(Assignee)

Comment 7

10 years ago
Created attachment 304431 [details]
Screenshot without global radio:hover rule at highcontrast inverse theme

It's needed Highcontrast inverse theme at least.

Screeenshot showing

http://developer.mozilla.org/samples/xultu/examples/ex_inputs_3.xul

without global |radio:hover| rule.

Comment 8

10 years ago
OK, I stand corrected.
Component: OS Integration → Theme
Doesn't this fix belong in a more general place? Why is it specific to preferences/pageinfo/addons?
(Assignee)

Comment 10

10 years ago
(In reply to comment #9)
> Doesn't this fix belong in a more general place? Why is it specific to
> preferences/pageinfo/addons?
> 

Because overriding hovered foreground/background color is specific to preferences/pageinfo/addons.
General radio has no problem. When it's hovered, both of foreground color and background color are changed.
(In reply to comment #10)
> Because overriding hovered foreground/background color is specific to
> preferences/pageinfo/addons.

Where are the style rules that override the hovered foreground/background color for preferences/pageinfo/addons? Shouldn't your patch change the same rules?
Attachment #304417 - Flags: review?(gavin.sharp)
Comment on attachment 304417 [details] [diff] [review]
Patch

need an answer to comment 11.
Attachment #304417 - Flags: review?(rflint)
Attachment #304417 - Flags: review?(gavin.sharp)
Attachment #304417 - Flags: review-
The fix belongs in http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/gnomestripe/global/preferences.css.
Component: Theme → Themes
Product: Firefox → Toolkit
QA Contact: theme → themes

Comment 14

2 years ago
Page Info is now OK with alternative Windows (high contrast) themes, and the prefs have moved to in-content, so I'm closing this as WFM.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.