1. Set pref to use Plaintext Composer 2. Select a msg with (possibly nested) quotes that are displayed in Mailnews with black bars. 3. "Edit Message As New" 4. Resend 5. Open the resent msg in the Mailnews viewer. Expected result: The resent msg looks like the original one, i.e. the quotes are displayed with black bars, i.e. the quotes are f=f quotes. Actual result: The quotes are displayed with ">", not black bars. I.e. the ">"s are considered content in f=f.

Reporter, Do you still see this problem on recent builds?

I have probably no time for Mozilla development the next couple of months so reassigning to default owner.

I still see this in BuildID 2002051509 (trunk). Now only the quotation gets garballed, but also the text no longer flows (e.g. "soft" line breaks turn into "hard" ones). In other words, all the f=f information gets lost!

Do you think it's the same prob that inserts spaces in the first column of the message when you do the following: 1. Set pref to use Plaintext Composer 2. Reply to any message which will quote the text 3. Save it as Draft and close the Composter 4. Edit Draft, change nothing and say send later (could be send either but it's unnecessary) Now look at the mail in Unsent Messages and no bars there, no colored quotings because of a blank before the > (unlike as in NS 4.x where spaces in front didn't matter). It seems to be f=f thing because after switching this of (via user_pref("mailnews.send_plaintext_flowed", true);) this doesn't happen (but all the flowing things gone of course).

I think, this is a dupe of bug 110949. f=f seem to have nothing to do with it. The problem seens to be that quotes are not recognized when the message is read. pi

Nobody answered my last comment. Is this still an in issue? pi

Status update: In BuildID 2003012513 (compiled on Red Hat 8.0, running on Red Hat 8.0.93) the problem seems indeed fixed. (Note that the bug 155622 mentioned in comment #3 is still there).