Build: 1999112908-M12 OS: RH6.0 In the Reply compose window, in the plain text format the quoted long line is not wrapped. But after receiving it, the quoted long line is wrapped in the message view pane. Steps of repro: 1. Compose a mail with a long line in the message body and send it to the testing account itself. 2. After receiving the mail, highlight the mail and click on Reply button. You'll see the quoted long line is not wrapped.

That's the normal behavior. Right rhp?

Yes, I believe this is correct. I tried some scenarios and I can't see where the behavior was broken. If you still think this is a problem, I need to know more details (i.e. compose in plain text, reply in HTML, reply in Plain text....) - rhp

Since 4.7 has the same behaviour, Verified as such.

*** Bug 153535 has been marked as a duplicate of this bug. ***

*** Bug 145900 has been marked as a duplicate of this bug. ***

*** Bug 192730 has been marked as a duplicate of this bug. ***

Look at the http://bugzilla.mozilla.org/show_bug.cgi?id=192730, which is marked as duplicate of this bug. There are steps to reproduce the bug and an attachment which has to be sent and replyed to. After you try to reply to that message, you will see quoted long unwrapped line in the reply. I think this is incorrect. In the comment #5 to bug#192730 it is said that it by design, but I think it is a wrong design. The option is "wrap plain text messages" but not "wrap new text in plain text messages". I understand that it can lead to strange and sometimes unneeded effects such as loss of formatting. But I use mozilla to write messages through a gateway which demands them to be wrapped at 72 characters, and because of that strange design, I need sometimes to reformat messages by hand which is very ugly. Maybe there should be option "Do not wrap rely lines", but I think that option "Wrap plain text message at" should wrap ALL and WHOLE messages.

I filed bug 196033 with your suggestion. pi

*** Bug 32100 has been marked as a duplicate of this bug. ***

*** Bug 124175 has been marked as a duplicate of this bug. ***