160970 - No line wrap when editing plain text messages saved in drafts folder. (or when using 'Reply')

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Robert Rose]

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.

Comment 1

[Serge Gautherie (:sgautherie)]

[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.

Comment 2

[Boris 'pi' Piwinger]

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

Comment 3

[Boris 'pi' Piwinger]

I see it in Linux 1.3b release.

pi

Comment 4

[Boris 'pi' Piwinger]

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

pi

Comment 5

[Boris 'pi' Piwinger]

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

Comment 6

[Serge Gautherie (:sgautherie)]

[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.

Comment 7

[Mike Cowperthwaite]

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.

Comment 8

[Mike Cowperthwaite]

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.

Comment 9

[Miguel]

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

Comment 10

[Peter Lairo]

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

Comment 11

[Scott MacGregor]

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

Comment 12

[(not reading, please use [e-mail] instead)]

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

Comment 13

[Magnus Melin [:mkmelin]]

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

->WFM

Comment 14

[Billy Newsom]

(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

Comment 15

[Magnus Melin [:mkmelin]]

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.