Closed Bug 855135 Opened 9 years ago Closed 9 years ago

Change link and signature colors in themes from hard-coded definitions to follow preferences


(Thunderbird :: Theme, defect)

Not set


(thunderbird22 fixed, thunderbird-esr17 unaffected)

Thunderbird 23.0
Tracking Status
thunderbird22 --- fixed
thunderbird-esr17 --- unaffected


(Reporter:, Assigned:




(2 files)

Now that bug 845807 has made the link colors and other color options (like using system colors or using/overriding colors defined by the document itself) available in the preferences UI, any hard-coded instances should be removed from the themes so that they actually follow the preference values. This specifically affects the display of plain-text messages and HTML messages which do not 

On Linux, all links are hard-wired to a light blue by a generic rule in

> /* ::::: message text, incl. quotes ::::: */
> a {
>   color: rgb(32,74,135); /* Sky Blue 3 */
> }

Mac OSX hard-wires only signature text and link colors to gray and light blue,

> /* ::::: signature ::::: */
> .moz-txt-sig,
> .moz-signature {
>   color: #505050;
> }
> .moz-txt-sig > a,
> .moz-signature > a {
>   color: #7777FF; /* light blue */
> }

I didn't find any link-related rules in the windows/ theme.
Depends on: 845807
For the signature text and links in particular, I think it still makes sense to de-emphasize them a little.

Having said that, I would be happy with changing the Mac block to something like:
> > /* ::::: signature ::::: */
> > 
> > .moz-txt-sig,
> > .moz-signature {
> >   opacity: 0.6;
> > }
> > 
> > .moz-txt-sig > a,
> > .moz-signature > a {
> >   /* delete this rule */
> > }

(0.6 seems to get it close to the current values to me…)
I just started to wonder how comes that the windows/ version gets away with not defining any specific font color for signatures here in the messageBody.css file, but then found that they are defined in the quoted content,

> .moz-txt-sig,
> .moz-signature {
>   color: rgb(136,138,133); /* Aluminum 4 */
> }
> .moz-txt-sig > a,
> .moz-signature > a {
>   color: rgb(114,159,207); /* Sky Blue 1 */
> }

Since those are not restricted to blockquote constructs they should also apply to the main text. Similar definitions can also be found for the linux/ theme.
Ok, so the reason that the signature is defined in messageQuotes.css for Linux and Windows but not for Mac OSX is that gMsgEditorCreationObserver uses it in the observe function to style the signature during message composition. For some reason, Mac OSX doesn't have that file and defines it in messageBody.css instead.

These should be enough pointers to come up with a patch, I'll give it a try but can only verify it for Linux and Windows, not Mac OSX (don't have one around).
Assignee: nobody →
Summary: Remove hard-coded link colors from the themes' messageBody.css definitions → Change link and signature colors in themes from hard-coded definitions to follow preferences
Looks good on Windows already, especially with the background color changed to something different than white. Basing the signature on opacity rather than that greyish font really helps in this case, and custom-colored links show up nicely.

I'll test the Linux version tomorrow and should have a patch up for your review after that, unless I run into any unexpected issues.
Attached patch Proposed patchSplinter Review
Here the patch for all platforms. This works fine on Linux as well, now the preference colors are obeyed without the "Allow content to choose its own colors" box unchecked, and the signature has opacity applied rather than a fixed color to also consider custom text colors.

Tested with both plain-text and HTML messages, including the signature on message composition (which doesn't use the display text and background colors though, but that's a different issue). In Simple HTML, the user-defined anchor color is chosen; in Original HTML, color specifications in the document are observed.

As said, I'm unable to test this on Mac OSX, but don't see a reason why it shouldn't work in a similar way.
Attachment #730150 - Flags: ui-review?(bwinton)
Attachment #730150 - Flags: review?(bwinton)
Note that you shouldn't see any opacity applied to the signature in message composition on Mac OSX given that it doesn't have a messageQuotes.css file (I don't see any bug report pending to add it, thus I can't tell if it was on purpose or by omission). The comment in the composition  code points to bug 517919 and bug 516322 for related discussion.
Attached image Comparison on Windows 7
Interesting, I assume that you determined this from Mac OSX?

The signature text color there is #505050 [rgb(114,159,207)] and #7777ff [rgb(119,119,255)] for the signature. In contrast, Windows and Linux define rgb(136,138,133) for the text and rgb(114,159,207) for links in signatures, thus are brighter than on Mac OSX for whatever reason.

Now, an opacity of 0.6 corresponds to rgb(101, 101, 101) for black, and 0.5 is rgb(127, 127, 127). As the latter is closer to the current shade (and that's what I've ended up using in bug 855684 for the SeaMonkey version of this patch, given that they currently use a matching 50% gray for the signature text), I've tried it as shown in this screenshot comparison. However, the link color is now lighter in Thunderbird (but not in SeaMonkey), thus it looks too pale now despite the gray text approximately matching the current shade.

Thus, unless you tell me to switch the opacity to 0.5 for Windows and Linux, I'd stick with 0.6 for all platforms given that it looks better for the in-signature links.
(In reply to rsx11m from comment #7)
> Interesting, I assume that you determined this from Mac OSX?

That refers to:

(In reply to Blake Winton (:bwinton) from comment #1)
> (0.6 seems to get it close to the current values to me…)
See Also: → 855684
Comment on attachment 730150 [details] [diff] [review]
Proposed patch

Seems pretty nice on Mac.  ui-r=me.

>+++ b/mail/themes/linux/mail/messageBody.css
>@@ -29,20 +29,16 @@ mailattachcount {
> /* ::::: message text, incl. quotes ::::: */
>-a {
>-  color: rgb(32,74,135); /* Sky Blue 3 */

I guess my only review-question for this patch is "Why did you remove this line?"

r=me with that answered.  (I'm guessing it's to let the user's chosen colour show, but I wanted to double-check that.)

Attachment #730150 - Flags: ui-review?(bwinton)
Attachment #730150 - Flags: ui-review+
Attachment #730150 - Flags: review?(bwinton)
Attachment #730150 - Flags: review+
(In reply to Blake Winton (:bwinton) from comment #9)
> I guess my only review-question for this patch is "Why did you remove this line?"

That's how I've noticed that something was wrong in the first place. On Linux, that rule currently overrides browser.anchor_color, thus a change there doesn't affect anything at all. I'd assume that this was introduced initially for the same reason the default link color was changed in bug 845807, to make the blue a bit lighter. This has been taken care of now by globally changing the default, thus the rule can go for that reason as well.
Keywords: checkin-needed
Whiteboard: [c-n: comm-central]
Comment on attachment 730150 [details] [diff] [review]
Proposed patch

Too bad, this has just missed the merge, thus requesting comm-aurora approval.

[Approval Request Comment]
Regression caused by (bug #): issue exposed by bug 845807
User impact if declined: fix for bug 845807 won't work on Linux and for signature links on all platforms
Testing completed (on c-c, etc.): developed and tested in 22.0 
Risk to taking this patch (and alternatives if risky): no impact on function, style changes only
Attachment #730150 - Flags: approval-comm-aurora?
Closed: 9 years ago
Flags: in-testsuite-
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [c-n: comm-central]
Target Milestone: --- → Thunderbird 23.0
Attachment #730150 - Flags: approval-comm-aurora? → approval-comm-aurora+
Depends on: 917906
Depends on: 920997
Depends on: 929006
You need to log in before you can comment on or make changes to this bug.