User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release) Build ID: 20130814063812 Steps to reproduce: <div> <p><span style="font-family: verdana,geneva;"><span style="color: #000000;"></span><span style="font-size: small;"><span style="color: #000000;">XXX TEXT XXX.<br /><br /><br /> &nbsp; <br /><br /><br /> XXX TEXT XXX<br /><br /><br /><big><strong>XXX TEXT XXX</strong></big><br /><br /><a href="XXX" target="_blank"><img style="border: 0;" src="JPG FILE" alt="XXX" width="250" height="130" border="0" /></a><br /><span style="color: #000000;"></span></span></span></span></p> <p><span style="font-size: small; font-family: verdana,geneva;"><span style="color: #000000;"><span style="color: #000000;"><em>XXX TEXT XXX<br /> </div> Actual results: In version V17.0.8 the signature text and image were all black, as stated in the HTML signature. In version 24 it is now gray, including the image, and can't be changed. Tried to change it's color to black in the message compose window but it doesn't work. I also checked the predefined color, in the Thunderbird options, and it set as Black. Expected results: Signature text and image should be Black (v. 17.0.8) instead of gray (v. 24)

Since Thunderbird now provides better access to text and link color preferences per bug 845807, the fixed colors for the signature were removed per bug 855135 and replaced with opacity, thus retaining any colors specified by the selected scheme. So, that change was on purpose. Consequently, any colors you've defined in your signature are subject to the opacity value. Note that this is a function of the default theme, thus other themes may apply different styles to the signature. http://kb.mozillazine.org/Signature_display_color#Outgoing_messages provides style code you can add to your own signature if you want to disable the graying of it when displayed in current Thunderbird/SeaMonkey mail clients. Further up, that article contains custom userChrome.css style code that can be applied to override the opacity setting of the default theme for all messages received.

Interesting comment from Xenos in http://gsfn.us/t/48xo9#reply_12996291 > I've just set up two additional mail clients, Opera and Claws. > Interestingly, both show plain text messages with a pale signature. > Both seem to honour the dash-dash-space convention too. But both show > the html version of the messages with a full-colour signature. > > If you are the kind of person who appreciates the virtues of plain > text, then the grey won't bother you. If you're the other sort of > person who wants the glitz and glamour of html in a signature, then > in general it won't be pale, EXCEPT for other Thunderbird users. This should be possible to distinguish. Plain-text messages trigger the ".moz-txt-sig" selector whereas HTML messages use the ".moz-signature" selector. To identify plain-text signatures in HTML messages, "pre.moz-signature" could narrow that down. Thus, two different rules with different opacity values, sounds feasible. Various screenshots of HTML signatures have been posted in forums where the grayed-out effect seems to (at least visually) be much stronger than the 60% opacity in the CSS rules. See https://d2r1vs3d9006ap.cloudfront.net/s3_images/960592/Clipboard.jpg?1379890120 for an example.

As another observation, the "opacity:" definitions actually nest and are accumulative. Thus, if there is a <div class="moz-signature"> clause within the signature itself, the part in it will be displayed with 60% of 60%, thus "opacity: 0.36" rather than "opacity: 0.6" and potentially producing the exaggerated effect seen in some of the presented samples. Thus, a more restrictive rule like "body > div.moz-signature" (didn't try) should be employed to only address the top-level signature <div> with a single opacity and not all descendants.

Adding the opacity also broke printing per bug 920997, so these issues need to be coordinated.

This patch needs to be applied on top of bug 920997 attachment 812647 [details] [diff] [review]. (In reply to rsx11m from comment #3) > Plain-text messages trigger the ".moz-txt-sig" selector [...] > To identify plain-text signatures in HTML messages, > "pre.moz-signature" could narrow that down. Isolating plain-text signatures in this way works and is implemented here, retaining the 0.6 opacity for those. For HTML signatures, I'd propose an 0.8 opacity value (i.e., half the transparency of plain-text signatures) as the compromise. I've also tested 0.85 which shows visually no effect any more, and 0.75 which I like a bit better but let's go with some reserves in case it's a matter of graphics cards and/or monitor parameters and settings. Anyway, this part probably should get some more testing with a variety of different signatures and computers, thus asking the theme experts for additional feedback. (In reply to rsx11m from comment #4) > As another observation, the "opacity:" definitions actually nest and are > accumulative. Thus, if there is a <div class="moz-signature"> clause within > the signature itself, the part in it will be displayed with 60% of 60%, thus > "opacity: 0.36" rather than "opacity: 0.6" and potentially producing the > exaggerated effect seen in some of the presented samples. An extreme case of this effect can be found in bug 921883 where 6 nested levels result in 3% remaining opacity, thus rendering the signature invisible. > Thus, a more restrictive rule like "body > div.moz-signature" (didn't try) > should be employed to only address the top-level signature <div> with a > single opacity and not all descendants. It's more complicated than that. There is also a div.moz-text-html node as a direct descendant of <body>, where div.moz-signature may be either parallel to it (for View > Message Body As > Simple HTML) or underneath it (for Original HTML), thus I need to distinguish those two cases individually.

Comment on attachment 812856 [details] [diff] [review] Reduce transparency for HTML I haven't a lot of HTML messages with a signature but the ones with it are looking good with this patch. There are also with nested .moz-signature and your rule is working flawlessly on them.

Comment on attachment 812856 [details] [diff] [review] Reduce transparency for HTML Review of attachment 812856 [details] [diff] [review]: ----------------------------------------------------------------- Yep, looks fine to me. I don't see any obvious issues with it. Thanks rsx11m! f+

Thanks for testing. Actually, I found an issue myself when using an HTML signature along with the reply-on-top/signature-above-quote setting. In this case, DOM Inspector tells me: body > div.moz-text-html > div.moz-cite-prefix > div.moz-signature and my second rule is no longer triggered. Thus, I've changed it to a more general rule of up to 3 nodes deep without any intermediate node being of class="moz-signature" to avoid being triggered multiple times by nested signature divs. Consequently, the mentioned case is caught by: body > :not(.moz-signature) > :not(.moz-signature) > div.moz-signature The default case is obviously not to apply transparency if neither of these rules is triggered, thus if in doubt the signature is left alone and shown with full opacity.

(In reply to rsx11m from comment #3) > Interesting comment from Xenos in http://gsfn.us/t/48xo9#reply_12996291 > > I've just set up two additional mail clients, Opera and Claws. > > Interestingly, both show plain text messages with a pale signature. > > Both seem to honour the dash-dash-space convention too. But both show > > the html version of the messages with a full-colour signature. This version of the patch modifies the first rule to apply to plain-text signatures only but doesn't add the second rule for div.moz-signature, thus leaving HTML signatures entirely alone. This is obviously simpler than the previous patch and would satisfy requests to display HTML signatures "as is" without any styles apply, but would also avoid de-emphasizing of HTML signatures which don't apply any own style.

Comment on attachment 813327 [details] [diff] [review] Proposed patch (v2) Review of attachment 813327 [details] [diff] [review]: ----------------------------------------------------------------- Code looks good. r+, also when I prefer v2b. But let's decide Blake which one should be used.

Comment on attachment 813610 [details] [diff] [review] Alternative patch (v2b) Review of attachment 813610 [details] [diff] [review]: ----------------------------------------------------------------- r+ I think we should use this one. HTML messages as also pages shouldn't be partly changed by the presenting device/software. I have some messages with special signatures and they are designed to be displayed as they are and we shouldn't apply a reduced opacity on them.

Thanks Richard. Yes, judging from the comments in the by now 16 threads on GetSatisfaction, not touching HTML signatures at all also seems to be the preference of the users who commented there (or making it optional, which would likely involve DOM manipulation by some JavaScript piece based on a preference, thus not in the scope for the upcoming 24.0.1 "dot" release).

Blake: Well, it would have been nice to get this (and the related/dependent-upon bug 920997) as a ride-along for 24.0.1 which was released today for the spell-check issue and has some other style fixes included... :-\ Given that the regular releases from esr24 are tagged about a week ahead of the scheduled release, I'd need a ui-review approved within a week in order to post the corresponding branch patch and get approval in time for the upcoming 24.0.2 release.

Comment on attachment 813327 [details] [diff] [review] Proposed patch (v2) Re-assigning to Josiah to get a quicker ui-r…

Comment on attachment 813610 [details] [diff] [review] Alternative patch (v2b) Re-assigning to Josiah to get a quicker ui-r…

I vote for v2b Some folks spend considerable time and effort composing html signatures, and could even consider it an artistic effort. We shouldn't arbitrarily change them. For my usage, I simply have been removing the class="moz-signature" before sending.

Comment on attachment 813327 [details] [diff] [review] Proposed patch (v2) Review of attachment 813327 [details] [diff] [review]: ----------------------------------------------------------------- Yeah, I agree. Let's do 2b.

Comment on attachment 813610 [details] [diff] [review] Alternative patch (v2b) Review of attachment 813610 [details] [diff] [review]: ----------------------------------------------------------------- This is quite nice. Let's go this route. Thanks rsx11m!

Thanks for the reviews, push of attachment 813610 [details] [diff] [review] for comm-central when possible please (and I'll post the branch patch for approval in a minute). As said, this needs to land after bug 920997 attachment 812647 [details] [diff] [review].

[Approval Request Comment] Regression caused by (bug #): bug 855135 User impact if declined: unwanted styling effect for HTML signatures Testing completed (on c-c, etc.): current trunk and release builds Risk to taking this patch (and alternatives if risky): low

Comment on attachment 813610 [details] [diff] [review] Alternative patch (v2b) [Approval Request Comment] see comment #22

Not sure of the current status of this baby, but my 2 cents worth... I spend a happy hour customizing my sigblock with fancy HTML graphics and colours so I am really happy with the artistic effect - Then TB decides to grey it out for me. Definitely NOT what I want. If my sigblock is valid HTML/CSS and I have specified HTML format, then I expect 'WISIWIG' behaviour: What I Set Is What I Get please. NickB

Comment on attachment 813610 [details] [diff] [review] Alternative patch (v2b) Sorry, I've picked the wrong approval flag here. :-\

I've found out that while my signature still shows up with less opacity when I send my e-mail, the reciever recieves it the way it was before, with full opacity. So it only shows wrong in thunderbird when I send it...

(In reply to mariska from comment #27) > I've found out that while my signature still shows up with less opacity when > I send my e-mail, the reciever recieves it the way it was before, with full > opacity. > So it only shows wrong in thunderbird when I send it... It is same with "quoting bars" (blocquote). In effect we see different message than our recipient. Sometimes it is very annoying and misleading... I wonder who thought it will be good idea to use styles visible in Thunderbird only. (In reply to mariska from comment #25) > Definitely NOT what I want. If my sigblock is valid HTML/CSS and I have > specified HTML format, then I expect 'WISIWIG' behaviour: What I Set Is > What I Get please. Exactly! It is why I do not use TB signatures anymore. Instead I load full HTML template, with signature embedded, in place where I want it, and in colors I want it.

Further brief test with reference to comments 25 and 27,28. The sigblock looks 'as it should' when viewed by a recipient in MS Outlook, but NOT when viewed using Thunderbird 24.0.1. P.S. 25 was me not Mariska...

Thanks for the comments, but the problem is well identified and the patch up for checkin/approval fixes it. Thus, no need for further analysis, and hopefully 24.0.2 will have the fix.

Hmm, what is wrong with those status flags? They have been cleared after marking the duplicate...

(In reply to rsx11m from comment #32) > Hmm, what is wrong with those status flags? They have been cleared after > marking the duplicate... Sorry for the inconvenience. There was a bug from this weekends tracking flag migration that cause some flags to be clear inadvertently when duping. Thanks for putting them back for us and the issue should be resolved now. dkl

Thanks.

Pushed to trunk to get landed for branches: https://hg.mozilla.org/comm-central/rev/e40d8939921f

https://hg.mozilla.org/releases/comm-aurora/rev/d36e4829de89 https://hg.mozilla.org/releases/comm-beta/rev/560797575ed2

Given the amount of attention this gets (currently 220 replies to http://gsfn.us/t/48xo9 alone) it should be worth to add an item to the 24.0.2 release notes; something like "The default theme does no longer de-emphasize HTML signatures by applying transparency."

I've modified the bug summary to better reflect what was done here while retaining the "gray" and "HTML" keywords in it.