Mozilla 1.0.1, wrap plain text messages at 66 characters, format flowed on I write a message like this: No. of chars: 12345678901 ........ 66 ---Message--- Hello, my name is Rene and I am writing a message using the Mozilla mail composer ---Message--- That is how the message is composed and that is the way it is sent out and saved in my Sent folder. I go to the sent folder and press 'Reply' to reply to my own message. Now my mail appears quoted like this No. of chars: 12345678901 ........ 66 ---Message after quoting--- > Hello, my name is Rene and > I am writing a message > using the Mozilla mail > composer ---Message after quoting--- You see that Mozilla has somehow re-wrapped my original posting. Line 1 is extended by a short word of line 2 and so on. You can quickly see the problem when writing very long mails. The original mail has 150 lines. After you have quoted it it has only 145 lines. This behaviour is not very disturbing as there are no manual line breaks in the message and we can assume that the message author does not mind where the line breaks exactly are. Nonetheless, Mozilla is editing the original posting. That must not happen. Steps how to reproduce: - Set "wrap plain text message after 66 chars" - Compose a long message - Send it away - Go to the "Sent"-folder - Reply to your own message - Sompare the quoted text to the original message - See that Mozilla rewrapped the original message disobeying the 66-chars-limit Possible solution: Either turn this automatic rewrapping off (best solution) or set the chars-limit for automatic re-wrapping to "chars-limit + number of quotation marks added (e.g. space + >)" René

Reporter, please attach the mails in question to this bug (mbox file). pi

One is the original posting, the other one is a reply (full quote). The quoting is copied and pasted into it. First you can see, that my last paragraph in the first posting is 7 lines long. After quoting it, it is only 6 lines long. The problem disobeying the char limit can then be seen when copying the quote and pasting it in again. Many lines a wrapped (of course as "> " was added) but some lines are wrapped in a way that 3 words are wrapped to the next line (one would be enough). I hope you get the point now. To say it in one sentence: Mozilla rewrapped text when quoting. That must not happen.

Thanks, let me see if we can sort things out. Your are using format flawed. Hence your own paragraphs are treated as on long line basically. When you do reply the lines are wrapped to look nicely who do not want format flawed (for good reasons;-), on the other side there are spaces to concatenate left, for those who want. So the rewrapping ist not really rewrapping, but a feature of f=f. As you say, if you enter hard line breaks, this won't happen. So what remains is your observation that the lines (now quoted) are longer than 66 characters. But note that the line length is for new text and not for quotes. pi

Ok, nonetheless text written f=f contains marks where to wrap the lines as f=f is a newline char followed by a space IIRC. I don't like that Mozilla disregards f=f linebreaks and I furthermore don't like that Mozilla disregards my char limit while disregarding the linebreaks. If you wite some text using f=f you see where the lines are broken and exactly that way the messages are displayed in any client that has no f=f. If any of these clients replies to that message the line breaks are put at the same position they have ben before. Mozilla wants to be a nice client and rewraps the original posting. As long as the content is the only important thing in this message this might be ok, but when formatting is important as well (using indents) Mizilla is about to botch the format. There is no good reason why Mozilla should reformat any text when quoting and there is no good reason why mozilla should furthermore reformat the text disobeying the chars-per-line- limit. To me it' a bug that Mozilla reformat texts when quoting.

Well, I guess this is WONTFIX (I also don't like it, hence simply not use format flawed). Probably a bug. Maybe you can find it somewhere. Marking NEW for QA to decide. pi

Not a dupe, I don't think;removing the DUPEME note. It is a bug; it seems that the rewrapping of the quoted text is done to the default width of 72. Note that if the quoted text is not f=f, it won't rewrap, and so long lines will still extend beyond the default width. Because this easy workaround exists, I'm reducing the severity of this bug to minor. In either case, using Edit|Rewrap will bring the text back within the desired margin. This looks related to bug 179266.

Updating summary so as not to trigger on search for 'rewrap' (a different function), and to mention the f=f dependency.

Revising my comment 6: By "easy workaround," I meant using Edit|Rewrap, as described in the subsequent paragraph. That was confusing. I misunderstood bug 179266; I no longer think it is related to this bug at all. René Stach: in your original complaint you wrote: > Either turn this automatic rewrapping off (best solution) or set the > chars-limit for automatic re-wrapping to "chars-limit + number of quotation > marks added (e.g. space + >)" These are two different goals. Is your priority to quote the original text as it arrived (what you called the "best solution"), or to get the quoted text within the wrap limit? This bug's summary (your original one, and the current one with my edits) indicates the second of these choices. If quoting the original text as it arrived is your priority, do you think that should be the case even if the original text was f=f? (Assume that the original text is sensibly encoded with f=f; it should be Mozilla's goal to avoid flowed formatting on text that shouldn't have it.) Note that if the preference mailnews.display.disable_format_flowed_support is set to true, then a quoted f=f message will not be rewrapped. I suggest that this particular behavior (whether to rewrap quoted text that originally was f=f) deserves a separate preference.

Dupe of bug 387687.

(In reply to Paolo Bonzini from comment #9) > Dupe of bug 387687. Related but not a duplicate; the bug here is about re-wrapping incoming messages created with f=f whereas the issue in bug 387687 occurs when replying to messages which don't have f=f applied but where it was emulated by incorrect usage of the quoted-printable line-wrapping mechanism.