User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041129 Firefox/1.0 (Debian package 1.0-3.backports.org.1) Build Identifier: 22.214.171.124 (20071031) I defined 2 IDs - say user1,user2. By chance, user1 had composition prefs set to 'start reply above msg text' while user2 had the saner 'start reply below msg text'. Default id is user1. So replying to a msg pops up the compose window as id user1, cursor on top, msg text at bottom. Switching ID on 'From:' selector to user2 wipes out the text window, leaving in just user2's signature. Seems that *only if both* IDs have same 'start reply below msg text' setting the msg text is preserved; in all other cases it's lost upon switching ID. Reproducible: Always Steps to Reproduce: 1. 2. 3.
It would be nice to have explicit Steps to reproduce (STR) for this bug, and/or find the dupe.
Severity: normal → major
Summary: msg body text disappears switching i'From:' identity → msg body text disappears when switching 'From:' identity to identity with different setting for "start my reply above the quote"
I can confirm this bug and in my case it applies to ALL identities no matter what composition prefs they have. Steps to reproduce are super easy: --------- 1. create two identities i1, i2 with signatures sig1 and sig2 2. compose email as i1 (signature shows under body text) 3. just before sending email switch identity to i2 most of typed body text + sig1 disappear and instead sig2 appears sometimes 1-2 lines from text are left UNDER sig2. --------- This happens no matter what preferences for sig above or sig under i have for the accounts.
Jorg, have you maybe fixed some of these in your recent signature placing fix?
I'm not aware of any body text we remove. Signature switch removes one single div node with class "moz-signature": https://dxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#5599 That was like this before I started and I haven't changed it. Body text will not be removed unless the signature was badly configured and the body was in fact typed into the signature. The reporter should use the DOM Inspector add-on to determine where body text was located.
This bug still exists and it works as reported by me last year above. The signature is not incorrectly formatted and any number of signatures types can be tried out with same results. There is a bug. Likely the removal of the div node picks up a few more things ...
More info: a solution to the problem is to introduce 2 empty new lines at the top of the signature -- but then the signature looks horrible when in the email since the two extra lines of space appear. I think this info should be enough to help debug the problem.
And yes, this bug has been around since 2008 at least if not longer. It was first reported here in 2008.
(In reply to smartiesxz from comment #5) > Likely the removal of the div node picks up a few more things ... The removal of the div which should contain the signature does exactly that. Remove a div. A div in HTML can contain a lot of things, so it you managed to type your body text into the signature, it will be removed. We won't be debugging this since you need to prove first that this is a problem. First check that the alleged problem exists in "safe mode". Next, submit the exact text of your signature. Then, create a draft message with that signature, enter your body, save the message. Attach the .eml file to the bug. And thirdly, download the "DOM Inspector" add-on I mentioned and inspect the structure of the message. I'll show you what I mean in an attachment.
Your reply is ridiculous. I explained exactly how to replicate the problem. I already spent hours on trying to fix this. Several people explained this is a problem. Your approach is condescending and absurd. I am an experienced computer scientist. This is just sad.
Created attachment 8738288 [details] Screenshot showing that body text and signature are well separated. In this case the signature is wrapped in a <pre> and not a <div>. Actually, the bug doesn't even state the TB version your using. Since TB 45 will be released soon, please do your testing with the latest TB 45 beta versions. Bugs in TB 38 are not interesting any more.
Jorg, all, I just updated to 38.7.2 (last update was maybe about 2 months ago) and I cannot replicate the problem anymore. This seems to have been fixed. I am curious if Thomas still has this. Jorg/gang, thanks for all the work on this!
Created attachment 8738293 [details] Video showing the function working. (In reply to smartiesxz from comment #9) > Your reply is ridiculous. I would kindly request the you observe the Bugzilla etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html I don't find anything ridiculous about giving some instructions of how to help us diagnose the problem. > I explained exactly how to replicate the problem. In fact you didn't. You didn't specify whether you used plain text or HTML or perhaps the content of a file. > I am an experienced computer scientist. I am an experienced Mozilla developer and Thunderbird Compose peer. > This is just sad. What is sad is that we will never get to the bottom of your problem, since you don't cooperate.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.