User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 When I select a block of text that has been forwarded inline, and in which the wrapping has been muckup up, then selected Edit | Rewrap, the wrapping is not modified at all. Reproducible: Always Steps to Reproduce: 1. Forward e-mail inline (plain text) 2. Select text of forwarded message 3. Edit | Rewrap Actual Results: Nothing Expected Results: Hard line breaks should have been removed.

Justin: I'm unable to reproduce this problem. Can you attach a sample email to this bug which exhibits the problem? (Save the email as a .EML file and use the Create New Attachment link above.)

When I forwarded the attached message, the text unwrapped. The attached message is the one that was left in my "sent" folder. When I try to forward it again, I get different results using the rewrap feature. If I select all text and do rewrap, it rewraps it ok. If I select all text underneath the header tables (to, from, subject, etc), and then do edit>rewrap, all text is converted to the format of my signature at the bottom, but it seems to wrap ok. If I select just the text between the header tables and my signature and do edit>rewrap, it converts all of the selected text to one really long line.

Thanks for the hint, Misty. I've been able to reproduce this bug now. There are actually several different behaviors which may be undesirable. This may need to be broken out as multiple bugs. -- Account set to compose as HTML: If original message is plain text (format=flowed or not), or original is HTML or multipart but displayed As Plain, the quoted text is placed within a <pre> block[1]: the lines are shown at their full length in both the compose window and the message-display window (horizontal scrollbar if necessary). Rewrap does not affect this text, unless (as noted in the report) the text selection includes some non-<pre> text after. (The Rewrap behavior when only part of the <pre> block is selected along with the text after, or with part of the message-headers table before, is somewhat unpredictable, and probably not desirable.) I'm pretty sure this is the problem Misty is seeing. An HTML message forward as HTML is not enclosed in a <pre> block, and so doesn't need to be rewrapped. [1] NOTE: Current 1.8a builds do NOT wrap the quoted text in a <pre> block, nor do they include the message headers: bug 246579. Until that bug is fixed, use 1.7 to work on this problem. -- Account set to compose as Plain Text: For plain or HTML messages, whether displayed as Plain or as HTML, when forwarded inline, the long lines are wrapped but not reflowed. This is also true for any account when using Edit As New on a plain-text or displayed-as- plain message. Rewrap does not affect those lines (which are copied, but not quoted), whether the funciton is run on the entire message or just on the selection, even after saving and reloading the draft. I think this is Justin's issue. This part is perhaps by design; if you type a bunch of lines in, with hard breaks inserted, running Rewrap on those does not reflow at the hard breaks. Generally speaking, Rewrap only changes the flow of *quoted* lines (seen in a reply). (There is also a problem in this regard where Rewrap forces hard line breaks in the typed-in text: bug 220575.) For the HTML case, you'd think Rewrap *ought* to work on the <pre> block, whether it is selected or not. (It does *something* for the quoted block in a reply, but I'm going to open *another* bug for that...) In fact, I'd say Rewrap makes no sense in an HTML composition *except* for a <pre> block, since the rest of the text flows naturally. What would be better would be for forwarded text that is known to be flowable (HTML source / format=flowed plain) to be reflowed automatically when forwarded inline (ref. bug 208128). This is the behavior for quoted text in a reply, and should apply to forwarded (and pasted) text as well; but that is not a rewrap issue. xref: bug 148673, bug 187997

Sample message, based on Misty's attachment; forward this inline to see the symptoms of this bug.

Another testcase, plain text this time.

Another testcase, f=f plain text this time.

The problem here is almost certainly happening because rewrap only wraps quoted lines, so a forwarded message would look like original text to the rewrap function, and hence would not be rewrapped. There's a comment in nsInternetCiter.cpp regarding this: // For now, don't wrap unquoted lines at all. // This is because the plaintext edit window has already wrapped them // by the time we get them for rewrap, yet when we call the line // breaker, it will refuse to break backwards, and we'll end up // with a line that's too long and gets displayed as a lone word // on a line by itself. Need special logic to detect this case // and break it ourselves without resorting to the line breaker. The editor's output functionality is a bit of a mess at the moment; it doesn't explicitly pass the line length to the serializer, so wrapping ends up happening automatically. Probably what needs to happen is for nsPlaintextEditor::Rewrap to call the serializer itself and explicitly specify no wrapping, instead of going through the editor convenience function SharedOutputString; then the code in nsInternetCiter could be safely changed to wrap original text as well as quoted text (probably optionally, since in a normal editing window, you don't want the original text hard-wrapped, you want it to rewrap in realtime as you add and delete text).

(In reply to comment #3) > For the HTML case, you'd think Rewrap *ought* to work on the <pre> block, > whether it is selected or not. (It does *something* for the quoted block in a > reply, but I'm going to open *another* bug for that...) Bug 249082. > What would be better would be for forwarded text that is known to be flowable > (HTML source / format=flowed plain) to be reflowed automatically when > forwarded inline Bug 249093.

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

(In reply to comment #8) In addition to the 2 bugs that you mentioned, I've been also following bug #196033, which is also related to rewrapping. We are still having this problem in version 1.0.2 (20050317). No one's really put any comments on these bugs for a long time. Any chance of them getting fixed?

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

Filter on "Nobody_NScomTLD_20080620"