Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 Not sure this is the right component. This is for the plain text mail editor. Try the following: Take an e-mail with lines of lenght your wrap column or longer. Reply. The text is quoted correcly. Save the message, close it. Go to your drafts folder. Choose edit draft. Now the quoted lines are broken like this: > here is a long quoted line, but one word > might show up in the next line, even though > it belongs to the quotes. Under conditions I could not yet identify that's the way the mail is actually sent. Sometimes the quotes remain correct, i.e.: > here is a long quoted line, but one word > might show up in the next line, even though > it belongs to the quotes. Further, it is not possible to edit the quotes in a way that you know what will happen. Try to bring the broken lines into one, it does not work. pi

WFM I have Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6+) Gecko/20011118

Akkana, do we have a bug on this ?

No, we don't have a bug on this. It's an interesting issue, and yes, it sounds like a valid bug (confirming). In the plaintext editor, we enclose quoted text in a <pre> so it won't be wrapped. But this only happens when we use InsertAsQuotation. We don't have any code to recognize quotes when we're reading in an existing file, and properly <pre> them. And yes, it probably would get sent this way. :-( I think the plaintext serializer relies on the <pre>, and doesn't try to recognize quotes itself. This should probably be on my list, at least initially, because I don't think anyone else cares about plaintext wrapping. Unfortunately I suspect the reading-in of the file is all handled by the parser and dom, and the editor doesn't have any say in it until it's too late, so I don't know how we're going to fix this unless the mail editor runs a pass over its dom tree after it's loaded looking for quotes to wrap (ugh!) Or maybe we could save the draft as html instead of plaintext, and keep the pre in place. We'll probably need a lot of cooperation from mail in order to fix this problem without inserting plaintext mail specific hooks into the parser. Cc'ing ducarroz since he's the one whose help we'd need. It's really a mail issue, not core editor (since it can't be reproduced without saving as draft, and the save as draft code may need to change to fix the problem).

Haven't heard any interest or concern from mailnews folks about this -- Future/helpwanted.

I am not sure, if the following is helpful or even related. When (again plain text) you start a line with > (to indicate that this is a quoted line) and go on typing. There will be an automatic line break. IOW: The editor does not understand that I want this quoted. I imagine that this happens here as well. The text is read from the draft, but not understood. This is 0.9.8 under Linux. pi

I just had another incident. I was working on a very long and important mail. For some reason Mozilla crashed, but I had saved my work. So I edited my draft to continue. Virtually all quotes were broken and no way to fix available. Actually, I had to save it, edit (quoted-printable) manually in vi and pipe it into sendmail. Most people will not be able to do this. So I set severity: major BTW: 0.9.9 pi

"Rewrap" should get your quotes back. That doesn't excuse this bug, but it's a workaround for when you find yourself bitten by it.

Actually, rewrap fixes only some lines. The problem seems to be worse. pi

I think we depend on bug 114954. This bug here has the problem that quote symbols are not recognized which actually is that bug. pi

See also bug 134439 -- some proposed solutions for that might also solve this problem (if we end up not expecting quotes to be wrapped in any special html tag).

I can't see how bug 134439 can do any good, neither alone nor here. Without WYSIWYG you even think that everything is fine, but what is actually sent is unreadable. pi

The problem here is that quotes are not marked as quotes when they're read back in from the drafts folder; they're just lines that happen to start with ">". Bug 134439 would make the mail window wrap to window width (which is invariably wider than the send wrapcol), so you wouldn't see the jagged quotes in the compose window; and it would make the output system treat all lines beginning with ">" as quotes, so the mail would also be sent correctly, detecting the quoted lines and not wrapping them rather than treating them like new unquoted text.

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

Marking OS/Platform=ALL because of dupe. pi

Is this caused by the same thing as bug 98315?

Seems likely they're the same problem, though I don't know how "edit message as new" is implemented.

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

trying to come up to speed on this. is this only for the plain text editor?

Seth, from Akkana's analysis, it should be only plain text. The reason should be that when reading a message from the Drafts mail file, which is essentially mbox, nothing is done to recognize what is a quoted line. If at this point we look for a > sign in the first column and mark those lines as quotes, it should work. pi

I have a possibly related bug, bug 161143, which I'd really like to address for this milestone (it's been a problem long enough) and I've been trying to come up with a good solution. One possibility is to have the editor, on InsertText, notice lines starting with "> " and flag them as quoted. I'm not happy with that, because it breaks generality of quoting (currently we can support aol-style quotes, and in theory other quoting styles, not that anyone actually knows about that or uses it), and it probably shouldn't happen from the normal "InsertText" so it should probably require a mail flag or a new "InsertTextWithQuotations" method, but it would solve this bug as well as bug 161143. Alternately, both mail and rewrap could parse their text and alternate between InsertText and InsertPlaintextQuotation, without requiring any editor API changes; but having to write the same code in two places is a sign that that's the wrong approach. So maybe I should just go ahead and write the new routine. Thoughts? Seth, can you think of a cleaner solution?

Also, please take a look at the other related bugs that are currently marked as dependencies of this one - bug 98315 and bug 114954. I would imagine that it should be pretty simple to fix bug 98315 while fixing this one.

Akkana, please don't look for "> ", but for ">" at the beginning of lines. I believe that you can fix not only this and bug 161143, but also bug 114954 as well as bug 98315 which is a dupe of this AFAICS. Furtermore related: bug 140884 pi

The patch I'm about to attach to bug 161143 should make this one easy to fix (just call InsertTextWithQuotes from edit draft instead of InsertText). Anyone want to point me to the code where edit draft calls insert text?

everything is done in the function nsMsgCompose::ConvertAndLoadComposeWindow. There is two paths in the function: one for plain text editor and one for html editor. Let me know if you need hep...

Thanks, J-F. Am I correct in thinking that the InsertText on line 583 of nsMsgCompose.cpp is the one that EditDraft is using? Is that the same line that is used by the "Edit Message as New" code path? Unfortunately, it turns out that nsMsgCompose still uses the editorshell, because I never got a review for bug 137629 (remove editorshell dependencies from mailnews). So this bug can't be fixed until that one is (I'm not going to add a new API to the long-obsolete nsIEditorShell). I expect the patch in that bug has bitrotted; I'll look at update it now, then I'll want reviews from someone in mailnews ...

correct, this is the one which insert a plain text message body during an edit draft/template, edit as new or forward inline.

Now that we have InsertTextWithQuotations, this becomes trivial and makes plaintext drafts much nicer. Ducarroz, can you please review?

Comment on attachment 103388 [details] [diff] [review] Easy fix R-ducarroz

Comment on attachment 103388 [details] [diff] [review] Easy fix sr=sspitzer

Comment on attachment 103388 [details] [diff] [review] Easy fix a=dbaron for trunk checkin

Fixed.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021108 (+ patches 101274, 101762) Verifying as reporter. pi

Note that there still exists another formatting problem with the "Edit draft" - bug 155622: Wrapping information lost on "Edit as new", "Edit draft" (RFC 2646 format=flowed)