Open Bug 1005466 Opened 7 years ago Updated 3 years ago
Large parts of quoted text eaten when send failed or "From:" is changed with enigmail installed
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140428193838 Steps to reproduce: I reply to larger message. Send failed (SMTP server rejected message). Or I change "From:" manually. Actual results: In both cases, large parts of the quoted text are eaten (disappear). My signature is added a second time instead. Expected results: Quoted text should not be destroyed. I suspect there is a bug in the algorithm that tries to exchange the signature for a new one. I have not experienced this problem before I got 24.4.0 on my Ubuntu 12.04 LTS by software update.
On a second thought, this could have to do with enigmail, which fiddles around with the message body. Maybe it is a bad interaction between failure of send or change of "From:" and enigmail.
(In reply to Andreas Abel from comment #1) > On a second thought, this could have to do with enigmail, which fiddles > around with the message body. Maybe it is a bad interaction between failure > of send or change of "From:" and enigmail. Hi Andreas. Did you come to a firm conclusion on this?
After disabling enigmail, I have not encountered the faulty behavior again. So I guess this concerns the interaction of enigmail and thunderbird. (It is a pity to having to disable enigmail, though...)
Summary: Large parts of quoted text eaten when send failed or "From:" is changed → Large parts of quoted text eaten when send failed or "From:" is changed with enigmail installed
Rowing back. I just witnessed the behavior again with disabled enigmail. Protocol: 1. composed message "From" account1 2. trying send 3. sending failed (SMTP rejected me) 4. selecting "From" account2 5. message body is mutilated 6. sending of (mutilated) message succeeds Do you need more info? Enabled Addons: CompactHeader 2.0.8 EDS Contact Integration 0.6 Messaging Menu and Unity Launcher integration 1.3.1 Disabled addons: Enigmail 1.6 Expiry Timestamp 1.4.1
Thunderbird version is now 24.5.0.
I think the bug is in the code that tries to delete the signature belonging to account1 and putting in the signature of account2. (In my case they are identical, but still stuff happens.) If I play around with a message that I edit and then switch the "From:" I get sometimes erratic results. For one, thunderbird seems to move stuff from below the signature to above of the signature. Like when I write stuff below the signature and then switch the From, it ends up above the signature. In one case it actually lost lines 5-7 from my signature (maybe it assumes somewhere that the signature is 4 lines). I would be curious to look at the code that does the signature patching. A priori, I would not be surprised if it is a heap of heuristics accumulated through the decades and going wrong now. (or just in my case.) Where is that code, can you offer a link?
Here is my signature: abel@agda:/etc/apt$ cat ~/dotfiles/.sig-gu Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden email@example.com http://www2.tcs.ifi.lmu.de/~abel/ abel@agda:/etc/apt$ I think I found (some version of) the code that does the signature switch: http://mxr.mozilla.org/comm-release/source/mailnews/compose/src/nsMsgCompose.cpp#5266 5265 NS_IMETHODIMP 5266 nsMsgCompose::SetIdentity(nsIMsgIdentity *aIdentity) It looks for the signature, which appears to be in a DOM node "moz-signature" (regardless whether we do html or plain-text editing!?). It starts from the last node and continues always with getPreviousSibling. If the node is found, it is deleted, and if the previous node is a <br>, it is deleted as well. I do not know anything about the internal data structure used for storing the text in the editor, however there could be a problem in the parser that takes a text file into the internal representation and identifies the signature as special to store in a "moz-signature" node. For instance, if I do "Edit Message as New" and switch sender, I get a second signature... Also, it happens when I delete the blank line before "--" and then switch Identity, a second "--" is inserted where the blank line was.
Here is a reproducible test case of slightly irritating (but harmless) behavior: 1. Compose a new message. You get <blank line> -- <contents of sig file> 2. Backspace from the second line, removing the <blank line>. -- <sig file> 3. Change identity. Result is -- -- <sig file> So it seems that removing the blank line already confuses the internal representation of the signature in the editor.
I guess I am getting to the core of the bug: 1. New message <blank> -- <sig1> 2. Cursor down and insert an arbitrarily long text right before the "--". <blank> <long text> -- <sig1> 3. Change to identity 2. The long text has disappeared. <blank> -- <sig2> 4. Thank you, thunderbird! Of course, there is no "undo" action for this. So it seems like the user can by accident put text into what thunderbird has marked as signature, even though the user does not edit the signature text itself, but starts right before it. SetIdentity then happily zaps whatever the user has put there. One principled way to fix this would be, instead of just zapping the whole "moz-signature" DOM entry plus preceding BR, check that the contents of "moz-signature" are actually the old signature. If the contents have been modified in any way by the user, the only safe behavior is not to delete the old signature, but just add the new one.
So could you reproduce this bug now? The handling of signatures seems also be broken when replying to a mail that has text below the signature of the sender. Upon "reply" this text is not included in the quote. I think the current behavior is a major problem, tempting me to look into other email clients.
Severity: normal → major
I did not experience this problem for a while, but yesterday I was upgraded to Thunderbird 31.6 (Ubuntu LTS 14.04), and the issue is back.
Version: 24 → 31
Skylined, can you reproduce this? (comment 7 - 9)
Yes, I can confirm Comment 9: the email body typed by the user disappears when switching to a different account in the "From:" field. (Apologies for the delay in reproducing, holidays and flu kept me occupied)
You need to log in before you can comment on or make changes to this bug.