in a textarea (like this in this page) when we press space the cursor "walks" until it reach the end of the textarea and at this time instead of warping to a new line it jumps to the last non-space character on the same line and stays there until a character different of space is pressed, and then is warps to a new line after that letter mozilla 0.9.5 2001101117 win98

I can confirm that. Moz 0.9.5 Win2k SP2

Confirm. Moz 0.9.5 Win2k SP2.

This is mostly intended behavior to prevent wrapping like: this is some happy text with three spaces between "foo" and "and" in "foo and and" So spaces are batched up on the previous line. The bug would be that the cursor goes to the beginning of the line, I guess.

confirmed on Linux

confirmed on Linux

This behaviour was introduced fixing a previous bug which meant that the space after the last column couldn't be used to wrap, instead it would appear at the beginning of the next line. The fix collapsed trailing spaces at the end of the line, so that they "would fit". Sadly I can't remember the bug number.

--> mozilla0.9.8

Moving to Mozilla 1.1 Engineers are overloaded with higher priority bugs.

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

I'm attaching a work in progress patch I've had sitting in my local tree for a while, which fixes this bug and allows us to wrap words that are wider than the content area. The actual fix for this bug is the following 3 lines (minus the comments) in nsTextFrame.cpp: @@ -4828,6 +4831,14 @@ aTextData.mX += dimensions.width; } else { + if (NS_STYLE_WHITESPACE_MOZ_PRE_WRAP == aTs.mText->mWhiteSpace) { + // In -moz-pre-wrap mode, we want trailing spaces that exceed + // the content area width to be compressed at the right edge + // of the content area. + + aTextData.mX = maxWidth; + } + // since we didn't add the trailing space width, set this flag so t hat // we will not trim this non-existing space aTextData.mTrailingSpaceTrimmed = PR_TRUE; but, I thought it just looked odd that spaces were still compressed at the maxWidth when we had scrollbars due to words that exceeded the width of the textarea. This patch works well, things left to do are: 1. Assess the impact of the word wrap change in Mail ... in terms of what the users sees and what gets sent after the content is run through the content serializer. 2. I noticed in one of my exagerated test cases (using a 120pt font) that I triggered some code in layout that aborts in debug builds when it detects that we've looped several thousand times, while resizing the content area, in realtime, so that it was smaller than one character in the font. 3. Perhaps address some of the XXX comments I added in the patch. This patch makes style="white-space: -moz-pre-wrap" behave like wrapping scheme used in the Mac TextEdit scenario described in bug 212456, which I think was the original intention.

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

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

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

Dupe of bug 87314, I think.