Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11 1. I tried to find this bug, it must exist before. I didn't find anything close. 2. I could not even find the right component to file this bug. Might be MailNews-Core, yet no component seemed to fit either. So here we go: 1. Reply to a (for sake of simplicity) plain text message using the HTML editor 2. Add text between the quoted text (by breaking the quoted text) 3. Observe that the impression is that quotes and your new text is vertically separated (looks like one line) 4. Send the message in plain text 5. Look at the sent version 6. Observe something like in this example: > Quoted part 1 Text I have written > Quoted part 2 > More text I have written > More quoted > text here > Even more I have written > Even more quoted. > > And again more quotes. > And more. > And the last I have written. 7. Note that between every of my text and every quote there was "one line" before sending. Observe that after sending there sometimes is no line, sometimes an empty quoted line. pi

Boris, you're seeing overzealous Format > Auto-Detect feature at work, which downconverts your HTML message to plaintext based on the mostly wrong assumptions that a) users prefer plaintext messages over HTML messages b) there's no "consequential" formatting in your message c) ux-wysiwyg can be sacrificed for the higher goal of sending plaintext as often as possible I agree with you that UX-wysiwyg is a high value and should be honoured much more strictly than we do now. In fact, I've often been angry myself when I saw the vertical spacing between quoted and reply sections of composition go away after sending. What you're seeing here is just the tip of the iceberg. To this day, Format > Auto-Detect removes entire tags which are clearly consequential to formatting/layout, like <pre> and <tt> (bug 414299). Worse, for a whole lot of unpredictable tags, it will dump any css formatting applied via style attributes to such tags (bug 414299, comment 108). However, we're having a hard time to convince the author of the Auto-Detect feature that violating UX-wysiwyg, no matter how much or little, is a form of dataloss and consequently, the code needs improvement. Alternatively, there's bug 136502 to provide ways of turning off Auto-Detect altogether, and simply send HTML always to achieve predictable formatting which honors UX-wysiwyg. Feel free to vote for those bugs (using vote button at the top) if you think they'll improve your user experience. Setting see-also link to bug 414299 because both bugs are caused by Format > Auto-Detect and the pattern of these bugs is exactly the same: users expect that we honor UX-wysiwyg by default.

About bug summary: Please forget about the whole concept of WYSIWYG in email. You don't know which client the other end uses. Esp. HTML email is often heavily - and in various different ways - stripped down, and as you very well know, many clients don't support HTML at all. Plus, we have many mobile clients recently, which will show things in a very different way anyway, due to various constraints, even if they support HTML. There is no such thing as "WYSIW the other person G" in email. About description: That said, what you report - the empty lines - is actually a genuine bug, a programming mistake. One which really annoys me, too. And it's already known, so DUPing.

(In reply to Ben Bucksch (:BenB) from comment #2) > About bug summary: > Please forget about the whole concept of WYSIWYG in email. Ben, bug 414299 and its duplicates have more than plenty of evidence that "forgetting about the whole concept of WYSIWYG in email" is a violation of a basic ux concept which the majority of our users are not willing to tolerate because it distorts their contents in a datalossy way, even full-scale dataloss when your Auto-Detect code randomly dumps css styles formatting without reason (bug 414299, comment 108). So no, we will not forget about it. > You don't know > which client the other end uses. Esp. HTML email is often heavily - and in > various different ways - stripped down, and as you very well know, many > clients don't support HTML at all. Plus, we have many mobile clients > recently, which will show things in a very different way anyway, due to > various constraints, even if they support HTML. There is no such thing as > "WYSIW the other person G" in email. Ben, please stop twisting our words. As several commenters have already explained to you in bug 414299, it is trivial and obvious that we can never *force* correct rendering upon the recipient, and if the recipient voluntarily chooses to view HTML-formatted mail in plaintext mode or even with a graphics viewer (for more distortion), we cannot stop him. However, our problem is not about the receiving end, it is about the HTML dataloss caused by Format > Auto-Detect between composition and sending. Our problem is that your Auto-Detect Code thinks it knows better than us which HTML formatting is relevant or not, and decides to discard valid HTML tags and (style) attributes that are undoubtedly consequential to the formatting of the message. All we are saying is that "what we see in composition (HTML-formatted msg) should be what we send (HTML-formatted msg)". The point being that after your Auto-Detect Code has stripped such formatting by downconverting to plaintext, there is absolutely *no way* that such formatting can ever be recovered on the receiving side. Whereas if we keep HTML formatting as HTML formatting in the sent msg, there's a good chance that the receiver will render that msg as HTML, and then it *will* look similar to what I sent (due to HTML standards). This is about the msg that gets sent, not about hypothetical limitations on the receiving side. Your argument (and your auto-detection code) runs like this: "The receiver *might* be color-blind, so what's the point of sending color? Let's just send black and white if we just have a little bit of color in the msg anyway". Which is obviously nonsense. I have never heard of any major email client that strips HTML when sending without explicitly being told to do so by the user. Furthermore, I don't believe that "many (major) clients don't support HTML at all". The fact that an HTML-formatted msg will look somehow "different" on a 7" mobile device than it looks on my 21" flatscreen, including variants in rendering certain formatting, is trivial and again, entirely irrelevant for the problems caused by stripping valid HTML upon *sending*, i.e. altering what gets *sent*. It's time to move on, to move forward. HTML mail has long ceased to be a problem in terms of bandwidth, storage capacities, and client rendering capabilities. There was a time when downconverting to plaintext made a lot of sense, and auto-detect was important to prevent problems, but that time is gone. Today, downconverting to plaintext is causing more problems than it solves. The only chance for auto-detect to survive at all is to adapt to those new circumstances, and stop messing with user's deliberate HTML formatting. If that means that we'll downconvert to plaintext much less often than now, than so be it. Otherwise, users will just switch it off as soon as we allow them to do so in bug 136502.