From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 BuildID: 2002072104 While editing an existing plain text message in the Drafts folder, the text does not rewrap. Reproducible: Always Steps to Reproduce: 1. I click Compose. 2. I type for awhile, don't finish message. 3. I click Save. 4. Later, I reopen message from Drafts folder. 5. I edit text typed in previous session, deleting a few words, for example. Actual Results: The edited text does not rewrap. Of course, even if I select the rewrap option, it doesn't rewrap because it isn't quoted text. This doesn't happen while composing HTML messages, only plain text messages. Expected Results: If I edit a draft of a plain text message, deleting or adding text to an already existing paragraph, that the paragraph should rewrap automatically as it would in HTML message editor.

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021212] Confirmed: re-editing a plain-text draft message before sending it ! I suggest to change the Severity from 'Normal' to 'Minor', as the obvious workaround is to rewrap manually.

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

I see it in Linux 1.3b release. pi

Bug 155622 is similar, but it also fails without format=flowed. pi

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

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624] I had one of theses when using "Reply" on a plain text message; while 'Edit as New' and 'Forward Inline' did rewrap automatically. Updating Sumarry. Changing (S) Normal -> Minor.

Robert Rose, Justin Kramer: if you are still paying attention to this bug, I am curious whether your symptom involved turning off 'format=flowed' (that is, if you had specifically changed the preference mailnews.send_plaintext_flowed to false). If not, you should add yourself to the CC list, and/or vote for, bug 155622, as that's your real problem. Boris apparently (comment 4) considers this bug distinct from that bug; however, the loss of reflow on editing a draft created with f=f is in fact distinct from the case without f=f. Either this bug should be separate and only for the NOT(f=f) case, or it should depend on 155622. A message saved to Drafts is saved with is saved in the same format it would be sent in. This means hard line breaks are written to the draft at the wrap points. For a message written out in f=f, a trailing space is written at each introduced line break, and the 'format=flowed' notation is added to the Content-type header. When the editor reads this draft, it ought to be able to use this information to restore the text to the same internal, flowable, state it had when the message was originally saved; the fact that it does not is 155622. However, when composed without f=f, no such cues are written; a line break is written at each wrap point and the whitespace at that point is removed. On reading the text back in, there is no means of telling where the user's hard breaks are vs. the breaks introduced by saving the text; therefore, it is not possible to restore the wrappable state on re-edit: the information needed to rebuild that state has been 'corrupted' by the introduction of additional hard breaks while writing out the draft. One way to solve this problem would be to *always* store drafts with f=f, regardless of the .send_plaintext_flowed preference. (Of course, this also requires fixing 155622.) Alternately, the saved text could be written with no introduced line breaks, just one line for each logical paragraph, then rewrapped on re-edit. (That fix would also work for 155622.) A message that has been *sent* with f=f turned off, and then re-edited from the Sent folder with Edit As New, has the same basic problem. In that case there is no workaround -- the stored mail in that case *must* have the hard breaks (and no trailing space) in place.

Serge Gautherie, I believe your addition of the 'or using Reply' case is misdirecting this bug; I'm not even sure what you expected the behavior to be for this case. (Perhaps you are talking about bug 161968?) It is true that editing the quoted text in a reply doesn't rewrap the text, even if the text is longer than the user's specified wrap point, or even if edits are made to the quoted text; I am not sure that is actually a problem. Even if it is, the internals of this issue are separate from the problem of reloading a draft with f=f turned off.; quoted text is handled differently from body text in the compose window. Note that if you reply to a message that was written with f=f, it will not reflow in the compose window, but it will reflow when viewed in a message window (e.g. opened from the Sent folder or the recipient’s Mozilla Inbox). Further, I find it hard to believe you have seen a case where Edit As New resulted in a message where the original text flows (i.e., "rewrap[s] automatically") as you claim. If you do have such a message, please save it as a .eml file and attach it to bug 155622.

This also happens with Mozilla 1.7. One more detail, it seems Mozilla wraps the text when opens the email. I mean, if you follow the steps to reproduce the bug and open the bad wrapped email and save it without changing the email, the email now is correctly wrapped

I don't consider this bug to be "minor". I re-edit previously stored messages very often (Edit Draft, Edit as New), and encounter this bug daily. It make messages hard to read and ugly. A very visible Thunderbird deficiency IMO. Nominating for Thunderbird 2.0

doesn't look like we've gotten any traction on this.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

I don't see this using the latest trunk build. Seems likely bug 155622 would have fixed it. ->WFM

(In reply to comment #13) This Bug IS NOT RESOLVED in either the Windows or Mac clients I use. (2.0.0.9 and a 1.5.0.14) Please reopen this bug. To Magnus Melin: please retry to do what the original reporter described. The lines do not rewrap when you open up a draft message, period. All wrapping is hard coded with carriage returns or line feeds, so the new edit window happily follows the old line splits. So we see both the old hard coded line splits and the new line wraps for long lines... the combination of the two means we have to manually remove all of the old line breaks. Perhaps when saving a text draft, we could have Thunderbird save it with a special X-Line-Wrap header, which when parsed by the second edit window, would tell it to remove the wrapped lines' carriage returns. Here is what my client might use... X-Line-Wrap: 76

It's just fixed in any stable release yet, you need a nightly trunk build: ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-trunk/ - what will become tb3.