104674 - in textarea, caret goes to start of line when spaces are kept from wrapping

Status: NEW

(Core :: DOM: Editor, defect, P5)

Description

[Daniel Mota Leite]

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

Comment 1

[Matthias R.]

I can confirm that. Moz 0.9.5 Win2k SP2                                        
                       

Comment 2

[Pauli Borodulin]

Confirm. Moz 0.9.5 Win2k SP2.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Syd Logan]

confirmed on Linux                                                             
                                                         

Comment 5

[Syd Logan]

confirmed on Linux                                                             
                                                         

Comment 6

[[e-mail]]

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.

Comment 7

[kinmoz]

--> mozilla0.9.8

Comment 8

[Kevin McCluskey (gone)]

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

Comment 9

[kinmoz]

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

Comment 10

[kinmoz]

Attachment: W.I.P. Patch 07/16/2003

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.

Comment 11

[Asa Dotzler [:asa]]

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

Comment 12

[Elmar Ludwig]

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

Comment 13

[David Tenser [:djst]]

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

Comment 14

[Mike Cowperthwaite]

Dupe of bug 87314, I think.

Comment 15

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.