Closed
Bug 929518
Opened 11 years ago
Closed 11 years ago
Received mail are barely visible. I noted these tag "<div class="moz-signature">" in the HTML message.
Categories
(Thunderbird :: Message Reader UI, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 917906
People
(Reporter: fbeloin, Unassigned)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Steps to reproduce:
I Create a signature by saving a message as HTML file. Send a message that contain it to someone and he respond to it.
Actual results:
The signature become shaded in gray. If I modify it and re-save it, it become more shaded. The more I do this the more it become barely visible. In the HTML file the tag <div class="moz-signature"> appear as often as I saved the signature.
If someone reply to my message or I check a message that I sent, all the historic of the conversation become shaded. I can't read my mail anymore since they've became shaded.
Expected results:
The signature and the message under it should not fade. I want to read it.
Reporter | ||
Comment 1•11 years ago
|
||
This looks like bug 921883 which in turn should be resolved with removal of the HTML-signature styling by bug 917906 in the upcoming 24.0.2 release.
> If I modify it and re-save it, it become more shaded. [...]
> In the HTML file the tag <div class="moz-signature"> appear
> as often as I saved the signature.
Interesting, this might explain why others have seen this nesting of "moz-signature" tags. I'm not able to reproduce this, though. Thus, can you explain how you create, edit, and re-save the signature to get some idea what might happen here?
Flags: needinfo?(fbeloin)
Reporter | ||
Comment 3•11 years ago
|
||
To create a signature:
--> I click to write a new message (blank, no signature assigned ere).
--> write something, insert some picture ...
--> File / save as / file / .html
--> Assigns this .HTML file to the signature of my Email account
From now, the HTML file does not contain the tag <div class="moz-signature">. Thunderbird seem to add this tag when he open it and append the signature to the mail.
Edit the signature:
--> I click write a new message (whit my signature assigned)
--> Backspace the two dash but not more
--> Edit the signature
--> File / Save as / File / .HTML
From now, the tag <div class="moz-signature"> appear once and when you will open the message editor thunderbird will apply two tag. The signature is faded twice. You can do this as often as you want.
This is how I get these tag in my signature, but I can't figure out why and when thunderbird add it in front of the other messages of the convesation like in the attachement I posted yesterday. And it does not happen on all mail I receive.
Flags: needinfo?(fbeloin)
Reporter | ||
Comment 4•11 years ago
|
||
Reporter | ||
Comment 5•11 years ago
|
||
Thanks for the additional information. So, it appears that despite removing the signature separator when re-editing the signature from a new mail, the underlying <div> isn't removed along with it. Thus, the signature context remains around the signature when saved as a file and is then doubled when attaching that signature to a new message.
I'm not sure if this can be considered a bug on its own (Wayne?) but I'd assume that this issue will become inconsequential once the fix for bug 917906 is out with 24.0.2, thus no styling will be applied any more to <div class="moz-signature"> constructs.
Flags: needinfo?(vseerror)
Comment 7•11 years ago
|
||
perhaps a better question for Joe
Flags: needinfo?(vseerror) → needinfo?(jsabash)
Comment 8•11 years ago
|
||
I don't think leaving the div tag warrants a new bug, since that probably involves core selection or editor components. I could point to many cases where empty tags are left in the composition, so it's not unique to sig editing.
Flags: needinfo?(jsabash)
Ok, thanks for the feedback, so let's declare this fixed with 917906.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•