Last Comment Bug 917906 - Signature in Gray in Version 24 (don't apply transparency to HTML signatures)
: Signature in Gray in Version 24 (don't apply transparency to HTML signatures)
Status: RESOLVED FIXED
[gs]
:
Product: Thunderbird
Classification: Client Software
Component: Theme (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: Thunderbird 27.0
Assigned To: rsx11m
:
:
Mentors:
https://getsatisfaction.com/mozilla_m...
: 918547 921883 925890 926054 926496 927401 928591 928923 929463 929470 929518 (view as bug list)
Depends on:
Blocks: 855135 920997
  Show dependency treegraph
 
Reported: 2013-09-18 09:34 PDT by telmo.quintas
Modified: 2014-03-13 06:12 PDT (History)
22 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
fixed
fixed
fixed
25+
fixed


Attachments
Reduce transparency for HTML (2.42 KB, patch)
2013-10-01 15:06 PDT, rsx11m
josiah: feedback+
richard.marti: feedback+
Details | Diff | Splinter Review
Proposed patch (v2) (2.64 KB, patch)
2013-10-02 14:44 PDT, rsx11m
richard.marti: review+
josiah: ui‑review-
Details | Diff | Splinter Review
Alternative patch (v2b) (1.99 KB, patch)
2013-10-03 12:40 PDT, rsx11m
richard.marti: review+
josiah: ui‑review+
standard8: approval‑comm‑aurora+
Details | Diff | Splinter Review
Branch patch (v2b) (2.02 KB, patch)
2013-10-11 15:33 PDT, rsx11m
standard8: approval‑comm‑beta+
standard8: approval‑comm‑esr24+
Details | Diff | Splinter Review

Description telmo.quintas 2013-09-18 09:34:41 PDT
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)
Comment 1 rsx11m 2013-09-19 15:28:14 PDT
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.
Comment 2 rsx11m 2013-09-19 15:46:52 PDT
*** Bug 918547 has been marked as a duplicate of this bug. ***
Comment 3 rsx11m 2013-09-25 20:39:36 PDT
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.
Comment 4 rsx11m 2013-09-26 07:03:08 PDT
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.
Comment 5 rsx11m 2013-10-01 07:22:06 PDT
Adding the opacity also broke printing per bug 920997, so these issues need to be coordinated.
Comment 6 rsx11m 2013-10-01 15:06:10 PDT
Created attachment 812856 [details] [diff] [review]
Reduce transparency for HTML

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 7 rsx11m 2013-10-02 07:49:35 PDT
*** Bug 921883 has been marked as a duplicate of this bug. ***
Comment 8 Richard Marti (:Paenglab) 2013-10-02 11:35:59 PDT
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 9 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-10-02 14:19:04 PDT
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+
Comment 10 rsx11m 2013-10-02 14:44:57 PDT
Created attachment 813327 [details] [diff] [review]
Proposed patch (v2)

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.
Comment 11 rsx11m 2013-10-03 12:40:48 PDT
Created attachment 813610 [details] [diff] [review]
Alternative patch (v2b)

(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 12 Richard Marti (:Paenglab) 2013-10-07 12:23:15 PDT
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 13 Richard Marti (:Paenglab) 2013-10-07 12:31:35 PDT
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.
Comment 14 rsx11m 2013-10-07 12:40:24 PDT
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).
Comment 15 rsx11m 2013-10-11 10:22:44 PDT
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 16 Blake Winton (:bwinton) (:☕️) 2013-10-11 11:06:57 PDT
Comment on attachment 813327 [details] [diff] [review]
Proposed patch (v2)

Re-assigning to Josiah to get a quicker ui-r…
Comment 17 Blake Winton (:bwinton) (:☕️) 2013-10-11 11:07:20 PDT
Comment on attachment 813610 [details] [diff] [review]
Alternative patch (v2b)

Re-assigning to Josiah to get a quicker ui-r…
Comment 18 Joe Sabash [:JoeS1] 2013-10-11 14:12:02 PDT
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 19 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-10-11 15:06:45 PDT
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 20 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-10-11 15:08:18 PDT
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!
Comment 21 rsx11m 2013-10-11 15:28:29 PDT
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].
Comment 22 rsx11m 2013-10-11 15:33:46 PDT
Created attachment 816125 [details] [diff] [review]
Branch patch (v2b)

[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 23 rsx11m 2013-10-11 15:34:57 PDT
Comment on attachment 813610 [details] [diff] [review]
Alternative patch (v2b)

[Approval Request Comment]
see comment #22
Comment 24 rsx11m 2013-10-12 09:55:06 PDT
*** Bug 926054 has been marked as a duplicate of this bug. ***
Comment 25 nick bunyan 2013-10-13 08:47:38 PDT
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 26 rsx11m 2013-10-13 11:34:45 PDT
Comment on attachment 813610 [details] [diff] [review]
Alternative patch (v2b)

Sorry, I've picked the wrong approval flag here. :-\
Comment 27 mariska 2013-10-13 23:08:55 PDT
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...
Comment 28 Arivald 2013-10-14 02:18:29 PDT
(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.
Comment 29 nick bunyan 2013-10-14 03:19:46 PDT
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...
Comment 30 rsx11m 2013-10-14 08:26:13 PDT
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.
Comment 31 rsx11m 2013-10-14 12:17:49 PDT
*** Bug 926496 has been marked as a duplicate of this bug. ***
Comment 32 rsx11m 2013-10-14 12:19:50 PDT
Hmm, what is wrong with those status flags? They have been cleared after marking the duplicate...
Comment 33 David Lawrence [:dkl] 2013-10-14 21:59:47 PDT
(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
Comment 34 rsx11m 2013-10-15 05:02:44 PDT
Thanks.
Comment 35 Mark Banner (:standard8) 2013-10-15 06:15:03 PDT
Pushed to trunk to get landed for branches:

https://hg.mozilla.org/comm-central/rev/e40d8939921f
Comment 37 KLB 2013-10-16 16:19:21 PDT
*** Bug 927401 has been marked as a duplicate of this bug. ***
Comment 38 rsx11m 2013-10-18 19:09:18 PDT
*** Bug 928591 has been marked as a duplicate of this bug. ***
Comment 39 rsx11m 2013-10-19 06:54:34 PDT
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."
Comment 40 rsx11m 2013-10-19 07:32:18 PDT
I've modified the bug summary to better reflect what was done here while retaining the "gray" and "HTML" keywords in it.
Comment 41 rsx11m 2013-10-21 05:05:06 PDT
*** Bug 925890 has been marked as a duplicate of this bug. ***
Comment 42 rsx11m 2013-10-21 06:36:10 PDT
*** Bug 928923 has been marked as a duplicate of this bug. ***
Comment 43 Kevin Stange 2013-10-21 09:40:12 PDT
*** Bug 929006 has been marked as a duplicate of this bug. ***
Comment 44 Mark Banner (:standard8) 2013-10-22 04:02:39 PDT
https://hg.mozilla.org/releases/comm-esr24/rev/b58e293b7622
Comment 45 rsx11m 2013-10-22 17:39:20 PDT
*** Bug 929470 has been marked as a duplicate of this bug. ***
Comment 46 rsx11m 2013-10-23 08:47:46 PDT
*** Bug 929463 has been marked as a duplicate of this bug. ***
Comment 47 rsx11m 2013-10-27 06:46:32 PDT
*** Bug 929518 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.