418568 - Hovered preferences headers should keep text color

Status: RESOLVED WORKSFORME

(Toolkit :: Themes, defect)

Description

[Takeshi Kurosawa :takenspc]

Attachment: 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.

Comment 1

[Takeshi Kurosawa :takenspc]

Attachment: Screenshot shows the problem (Highcontrast inverse theme)

Comment 2

[Reed Loden [:reed]]

Please request review from [e-mail].

Comment 3

[Takeshi Kurosawa :takenspc]

Comment on attachment 304417 [details] [diff] [review]
Patch

reed, thanks your comment :-)

Comment 4

[Michael Ventnor]

Aren't there just CSS rules you could remove somewhere that makes this change in the first place?

Comment 5

[Takeshi Kurosawa :takenspc]

(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

[Michael Ventnor]

(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.

Comment 7

[Takeshi Kurosawa :takenspc]

Attachment: 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

[Michael Ventnor]

OK, I stand corrected.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Doesn't this fix belong in a more general place? Why is it specific to preferences/pageinfo/addons?

Comment 10

[Takeshi Kurosawa :takenspc]

(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.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

(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?

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 304417 [details] [diff] [review]
Patch

need an answer to comment 11.

Comment 13

[Dão Gottwald [:dao]]

The fix belongs in http://mxr.mozilla.org/mozilla-central/source/toolkit/themes/gnomestripe/global/preferences.css.

Comment 14

[:Gijs (he/him)]

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.