Signature in Gray in Version 24 (don't apply transparency to HTML signatures)

RESOLVED FIXED in Thunderbird 27.0

Status

Thunderbird
Theme
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: telmo.quintas, Assigned: rsx11m)

Tracking

Trunk
Thunderbird 27.0
Dependency tree / graph

Thunderbird Tracking Flags

(thunderbird25 fixed, thunderbird26 fixed, thunderbird27 fixed, thunderbird_esr2425+ fixed)

Details

(Whiteboard: [gs], URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

4 years ago
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)
(Assignee)

Comment 1

4 years ago
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.
(Assignee)

Updated

4 years ago
Duplicate of this bug: 918547
(Assignee)

Updated

4 years ago
Component: Message Compose Window → Theme
(Assignee)

Updated

4 years ago
(Assignee)

Comment 3

4 years ago
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.
(Assignee)

Comment 4

4 years ago
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.
Status: UNCONFIRMED → NEW
status-thunderbird_esr24: --- → affected
Ever confirmed: true
(Assignee)

Updated

4 years ago
Blocks: 855135
(Assignee)

Updated

4 years ago
Blocks: 920997
(Assignee)

Comment 5

4 years ago
Adding the opacity also broke printing per bug 920997, so these issues need to be coordinated.
(Assignee)

Comment 6

4 years ago
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.
Attachment #812856 - Flags: ui-review?(bwinton)
Attachment #812856 - Flags: feedback?(richard.marti)
Attachment #812856 - Flags: feedback?(josiah)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 921883
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.
Attachment #812856 - Flags: feedback?(richard.marti) → feedback+
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+
Attachment #812856 - Flags: feedback?(josiah) → feedback+
(Assignee)

Comment 10

4 years ago
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.
Assignee: nobody → rsx11m.pub
Attachment #812856 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #812856 - Flags: ui-review?(bwinton)
Attachment #813327 - Flags: ui-review?(bwinton)
Attachment #813327 - Flags: review?(richard.marti)
(Assignee)

Comment 11

4 years ago
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.
Attachment #813610 - Flags: ui-review?(bwinton)
Attachment #813610 - Flags: review?(richard.marti)
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.
Attachment #813327 - Flags: review?(richard.marti) → review+
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.
Attachment #813610 - Flags: review?(richard.marti) → review+
(Assignee)

Comment 14

4 years ago
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).
(Assignee)

Updated

4 years ago
OS: Windows Vista → All
Hardware: x86_64 → All
Version: 24 → Trunk
(Assignee)

Comment 15

4 years ago
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…
Attachment #813327 - Flags: ui-review?(bwinton) → ui-review?(josiah)
Comment on attachment 813610 [details] [diff] [review]
Alternative patch (v2b)

Re-assigning to Josiah to get a quicker ui-r…
Attachment #813610 - Flags: ui-review?(bwinton) → ui-review?(josiah)

Comment 18

4 years ago
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.
Attachment #813327 - Flags: ui-review?(josiah) → ui-review-
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!
Attachment #813610 - Flags: ui-review?(josiah) → ui-review+
(Assignee)

Comment 21

4 years ago
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].
Keywords: checkin-needed
Whiteboard: [gs] → [gs][c-n: comm-central, push *after* bug 920997]
(Assignee)

Comment 22

4 years ago
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
Attachment #813327 - Attachment is obsolete: true
Attachment #816125 - Flags: approval-comm-esr24?
Attachment #816125 - Flags: approval-comm-beta?
(Assignee)

Comment 23

4 years ago
Comment on attachment 813610 [details] [diff] [review]
Alternative patch (v2b)

[Approval Request Comment]
see comment #22
Attachment #813610 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

4 years ago
status-thunderbird25: --- → affected
status-thunderbird26: --- → affected
status-thunderbird27: --- → affected
(Assignee)

Updated

4 years ago
Duplicate of this bug: 926054

Comment 25

4 years ago
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
(Assignee)

Comment 26

4 years ago
Comment on attachment 813610 [details] [diff] [review]
Alternative patch (v2b)

Sorry, I've picked the wrong approval flag here. :-\
Attachment #813610 - Flags: approval-mozilla-aurora? → approval-comm-aurora?

Comment 27

4 years ago
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

4 years ago
(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

4 years ago
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...
(Assignee)

Comment 30

4 years ago
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.
(Assignee)

Updated

4 years ago
status-thunderbird25: affected → ---
status-thunderbird26: affected → ---
status-thunderbird27: affected → ---
status-thunderbird_esr24: affected → ---
Duplicate of this bug: 926496
(Assignee)

Comment 32

4 years ago
Hmm, what is wrong with those status flags? They have been cleared after marking the duplicate...
status-thunderbird25: --- → affected
status-thunderbird26: --- → affected
status-thunderbird27: --- → affected
status-thunderbird_esr24: --- → affected
(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
(Assignee)

Comment 34

4 years ago
Thanks.
Pushed to trunk to get landed for branches:

https://hg.mozilla.org/comm-central/rev/e40d8939921f
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 27.0
Attachment #813610 - Flags: approval-comm-aurora? → approval-comm-aurora+
Attachment #816125 - Flags: approval-comm-beta? → approval-comm-beta+
https://hg.mozilla.org/releases/comm-aurora/rev/d36e4829de89
https://hg.mozilla.org/releases/comm-beta/rev/560797575ed2
status-thunderbird25: affected → fixed
status-thunderbird26: affected → fixed
tracking-thunderbird_esr24: --- → 25+
Keywords: checkin-needed
Whiteboard: [gs][c-n: comm-central, push *after* bug 920997] → [gs]
(Assignee)

Updated

4 years ago
status-thunderbird27: affected → fixed

Updated

4 years ago
Duplicate of this bug: 927401
(Assignee)

Updated

4 years ago
Duplicate of this bug: 928591
(Assignee)

Comment 39

4 years ago
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."
Keywords: relnote
(Assignee)

Updated

4 years ago
Summary: Signature in Gray in Version 24 (Color as Black set in HTML) → Signature in Gray in Version 24 (apply transparency for plain-text signatures only)
(Assignee)

Comment 40

4 years ago
I've modified the bug summary to better reflect what was done here while retaining the "gray" and "HTML" keywords in it.
Summary: Signature in Gray in Version 24 (apply transparency for plain-text signatures only) → Signature in Gray in Version 24 (don't apply transparency to HTML signatures)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 925890
(Assignee)

Updated

4 years ago
Duplicate of this bug: 928923

Updated

4 years ago
Duplicate of this bug: 929006
Attachment #816125 - Flags: approval-comm-esr24? → approval-comm-esr24+
https://hg.mozilla.org/releases/comm-esr24/rev/b58e293b7622
status-thunderbird_esr24: affected → fixed
(Assignee)

Updated

4 years ago
Duplicate of this bug: 929470
(Assignee)

Updated

4 years ago
Duplicate of this bug: 929463
(Assignee)

Updated

4 years ago
See Also: → bug 929006
(Assignee)

Updated

4 years ago
Duplicate of this bug: 929518
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.