87314 - Strange multiple whitespace behaviour after bug 19265 fixed

Status: NEW

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

Description

[[e-mail]]

Using Build ID: 2001062004
Steps to reproduce problem:
1. Find a textarea e.g. Bugzilla Comment
2. Type a sentence which stops (.period) one space away from the end of the line.  
3. Type two spaces.

Expected results: Cursor sticks (or possibly line wraps).
Actual results: cursor moves backwards on the second space.

While you are unlikely to find large runs of spaces, two after a . is common.

Comment 1

[anthonyd]

ok, this doesnt move backwards anymore, but it still isnt working as expected I 
would think.

Now if you do as the testcase explains, instead of the cursor moving backwards, 
the spaces are being added into the content model, you just cant see, and there 
is no behavior to reflect this.  In other words, no wrapping or anything

If you do the above testcase, and after the period hit space like 20 times or 
something, and then with the mouse you click right after the period and hit 
return, you will see the spaces appear on the next line.

Anyway, not a table specific bug, over to core owner.

Comment 2

[[e-mail]]

The behaviour still works as described in build 2001120504, but an easier way to
duplicate it is just to type 100 or so spaces in an empty textarea.

Comment 3

[Kevin McCluskey (gone)]

Reassigning to Kin.

Comment 4

[Christopher Hoess (gone)]

change component

Comment 5

[Mike Cowperthwaite]

A more precise description of the symptom is that end-of-line spaces will be 
shown as typed *until* the wrap column is passed, at which point all the spaces 
will collapse to zero width.
This is only the case for "plain text" entry (textareas, plain-text mail); the 
HTML editor has a different behavior, converting earlier spaces into nbsp's.

Comment 6

[Mike Cowperthwaite]

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

Comment 7

[Mike Cowperthwaite]

I think bug 104674 is a dupe of this, and there's an (old) W.I.P. patch at that bug which might be salvageable.

Comment 8

[Mike Cowperthwaite]

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

Comment 9

[Mike Cowperthwaite]

(In reply to comment #5)
> A more precise description of the symptom is that end-of-line spaces will be 
> shown as typed *until* the wrap column is passed, at which point all the
> spaces will collapse to zero width.

In current builds, the spaces collapse to a single space, not zero-width -- a result of bug 235223, I think.  This change is an improvement, I think, but there is still the symptom of some number of spaces suddenly collapsing, with the caret "moving backwards" as described in comment 0.  Whether it should be fixed, I don't know (see the discussion at the just-duped bug 205547); I don't mind the current behavior, personally.

Bug 195513

Comment 10

[Mike Cowperthwaite]

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

Comment 11

[Mike Cowperthwaite]

I noticed a pertinent behavior in gedit (2.14.4, running on Ubuntu 6.06).  If the caret moves beyond the wrap point due to typing a space, it wraps all the way back to the beginning of the word, so you can see explicitly how many spaces are following.  I don't know if that's worth mimicing or not.


I left comment #9 unfinished...
> Bug 195513
... is the mail composition bug for this same issue.

Comment 12

[Owen Ward]

This bug should be fixed. All spaces entered in a text field should be displayed as they are typed. The way it works now, spaces entered to the right of the last character on a line are not displayed. Here is an example: I enter test word 'abc'               followed by 15 spaces. 'abc' was at the end of the third line, 'followed' appears on the fourth line. None of those spaces are currently displayed. If I copy and paste this text into Notepad, the spaces are displayed as entered.

Comment 13

[Makoto Kato [:m_kato]]

old bug.  down to P3