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.

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.

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.

Reassigning to Kin.

change component

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.

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

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.

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

(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

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

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.

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.

old bug. down to P3