User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2) Gecko/20021126 In some instances of rewrapping, an extra space is inserted at the beginning of a line within a paragraph. This happens when the line above is one character short of the set wrapping width, including any trailing space. Reproducible: Always Steps to Reproduce: 1. Have line wrapping width set to 72 (the default). 2. Copy and paste this text into a message: > The quick brown fox jumps over the lazy dog. Jackdaws love my big > sphinx of quartz. The five boxing wizards jump quickly. Quick Baz, > get my woven flax jodhpurs. Pack my box with five dozen liquor jugs. > Waltz, bad nymph, for quick jigs vex. 3. Do Options -> Rewrap a few times. Actual Results: The first rewrap, when there are no spaces at the ends of lines, appends a space to each of the first and second line, and to the beginning of the fourth: > The quick brown fox jumps over the lazy dog. Jackdaws love my big > sphinx of quartz. The five boxing wizards jump quickly. Quick Baz, > get my woven flax jodhpurs. Pack my box with five dozen liquor jugs. > Waltz, bad nymph, for quick jigs vex. The second time, the extra space has moved to the beginning of the third line, causing "jugs" to run onto the fourth line. The third time, all lines are indented correctly. Subsequent iterations alternate the result between those of the second and third times. Expected Results: Kept all lines indented by a > and _one_ space throughout the operation.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030117 I see it. Assigning to Akkana. pi

I've seen this too. The algorithm needs some whitespace love. The editor has some very similar code (which Joe recently put some work into improving), and I've hoped that that code could be exposed rather than reimplementing the wheel and adding bloat. With any luck some day Joe and I will have some spare time to get together and make this happen.

Is this plaintext mail? html? both? In plaintext all spaces are visible. The code Akkana refers to is used for determining what whitespace does not render in html. If this problem is in plaintext mail then that implies it doesn't have a connection to the logic in nsWSRunObject.

I assume plaintext mail is being discussed, since that's the vast majority of rewrap use. Doesn't the WSRun code come into play for issues like wrapping of lines in plaintext textareas? Or is that completely separate layout code?

It's seperate, and in layout. The only thing the editor does wrt wrapping is in html, and there all we do is make two consecutive spaces be an nbsp followed by a space (if possible), rather than the other way around. This is so the layout linebreaking code will keep both the spaces at the end of the top line, rather than splitting them and putting one at the front of the bottom land.

My mistake -- removing dependency.

Is this bug a dupe of bug 121898? (Note that bug was repurposed from its original report, starting in bug 121898 comment 7.)

Not sure. Do we want to treat bugs as being about what they were originally about, or about what somebody tried to turn them into, particularly when there's no overlap between the two? Or is there overlap in the mere sense that the steps to reproduce are the same, but the effect is different?

It's really Akkana's call whether this is a dupe or not; I wanted to flag the similarity in the erroneous results.