User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082803 NotreDame/Library SeaMonkey/2.0a1pre Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082803 SeaMonkey/2.0a1pre SeaMonkey Mail is not breaking lines where they should be, so text is wrapping improperly. I'm attaching the source of an e-mail I sent, and and image of what it looked like when I received it. Reproducible: Sometimes Steps to Reproduce: 1.I've noticed a similar effect previously in the last couple of months, but only a couple of times. I compose mail with mailnews.wraplength = 0 .

I've noted in the image how I would expect it to be displayed. There should be a blank line before the line beginning with "1)". The line beginning with "2)" should be on a new line rather than being appended to the end of the line beginning with "1)".

I noticed the same effect in another e-mail I just sent. I've discovered that the problem is a line ends in a space followed by a CRLF, the following line will be appended to it when displayed in the mail view window. Take a look at the line that begins with "1)" in the first attachment. If you highlight it, you'll see that it ends in a space. This is also happening in SM 1.1.4.

> Content-Type: text/plain; charset=ISO-8859-1; format=flowed This is part of the reason for your observation, the plain-text e-mail is sent with f=f set, thus a space at the end of the line is interpreted as a "soft" line break. Thus, the display is following the encoding in accordance with RFC3676. The important question is why the spaces are added during composition. Unable to reproduce this, with or without mailnews.wraplength = 0.

Ok, I just figured that I missed an item in my testing. You actually have to type (or copy-paste) the space at the end, *and* mailnews.wraplength has to be set to zero, then any space between the last word of a line and the CRLF is not stripped. This does not happen with the default 72 wrap length. This may be a duplicate of bug 261467, if you only observe this behavior under the given conditions but not if the lines you type do not end in a space.

Well, this is curious. I've been very careful to try not to end lines with a space as I compose new e-mail so as to avoid the problem. I just tried sending myself a couple of e-mails with lines ending in a <space>CRLF . The space is being stripped when sent, as apparently is should be, so I'm no longer seeing the lines wrap incorrectly. Used to be, if I sent this to myself Now is the time for<space>CRLF all good men. I'd receive this Now is the time for all good men. Today when I receive it it looks just like it did when I sent it, but without the trailing <space> . Am I understanding correctly that you were able to duplicate the issue? I don't seem to be able to duplicate it anymore. Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008040302 SeaMonkey/2.0a1pre

(In reply to comment #6) > Am I understanding correctly that you were able to duplicate the issue? I don't > seem to be able to duplicate it anymore. I was able to reproduce this with the 1.1.9 branch release, but not in the current SeaMonkey/2.0a1pre nightlies, sorry for being inaccurate here. I can still type the space at the end in trunk, but it is removed when sending. There was a set of patches approved for bug 261467 to fix this, then it moved to another patch in bug 215068 because of the separator line. This was checked in by the end of last year. Thus, if it works for you now, your bug should represent the same issue as bug 261467.

OK, thanks. Should I go ahead then and mark this is a duplicate of bug 261467 ? BTW, if you're wondering why I set mailnews.wraplength = 0 , it's because of bug 353746 .

Ok, in that case you should probably disable f=f to get a correct wrap, by setting mailnews.send_plaintext_flowed to false. Then, the plain-text e-mail would retain exactly the spacing and line breaks as you entered them.