They labels on disabled toolbarbuttons are too washed out compared to cocoa apps. One can hardly read the labels.

We shouldn't be using GrayText for disabled toolbarbuttons. The native color for this is #3F3F3F. We've got these options: - Hardcode the color to #3F3F3F in the CSS, - find a platform color that's #3F3F3F and use that (is there one?), or - introduce a new platform color for "disabled text on dark chrome". If we use a platform color, we should find out if there's a way to get it from the system. However, this might be a problem because it will probably different on 10.4...

Let's go for option 3.

Comment on attachment 351983 [details] [diff] [review] part 2, v1: use the color in the CSS "toolbartextdisable" is strange... disabledToolbarText instead?

Yeah, it's strange... I did it because it's similar to the already-existing -moz-mac-menutextdisable, but I'm fine with disabledToolbarText.

pushed as -moz-mac-disabledtoolbartext (we don't use intercaps in color names): http://hg.mozilla.org/mozilla-central/rev/a72ce0279ba8 http://hg.mozilla.org/mozilla-central/rev/a441f54e2c64

(In reply to comment #7) > (we don't use intercaps in color names) We do, but apparently, for some or for no reason, only if it's a spec'd color (GrayText, HighlightText, ThreeDShadow, etc.)

Oh, yeah, I didn't even think about those without -moz prefix...

(In reply to comment #8) > (In reply to comment #7) > > (we don't use intercaps in color names) > > We do, but apparently, for some or for no reason, only if it's a spec'd color > (GrayText, HighlightText, ThreeDShadow, etc.) It's recommended to use the css2 system color values with "mixed capitalization" (http://www.w3.org/TR/CSS21/ui.html#system-colors), so I guess that's why we do it.

Comment on attachment 351983 [details] [diff] [review] part 2, v1: use the color in the CSS Asking for approval1.9.1: the patches are trivial and at least in Thunderbird the problem is quite visible.

(In reply to comment #10) > (In reply to comment #8) > > (In reply to comment #7) > > > (we don't use intercaps in color names) > > > > We do, but apparently, for some or for no reason, only if it's a spec'd color > > (GrayText, HighlightText, ThreeDShadow, etc.) > > It's recommended to use the css2 system color values with "mixed > capitalization" (http://www.w3.org/TR/CSS21/ui.html#system-colors), so I guess > that's why we do it. Yeah, I was wondering why we /don't/ do it for prefixed values (except for -moz-Dialog and -moz-DialogText).

Comment on attachment 351982 [details] [diff] [review] part 1, v1: add color -moz-mac-toolbartextdisable a191=beltzner

Comment on attachment 351983 [details] [diff] [review] part 2, v1: use the color in the CSS a191=beltzner

Landed on 1.9.1: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fc5d2a94d91d http://hg.mozilla.org/releases/mozilla-1.9.1/rev/08bdbc38e74b

Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090312 Shiretoko/3.1b4pre Verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090312 Minefield/3.2a1pre

This bug's priority relative to the set of other polish bugs is: P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable. effects the main window but required customization, issue was clearly visible.