482484 - Caret can be placed before first start element in contentEditable elements

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[spam]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2a1pre) Gecko/20090310 Minefield/3.2a1pre

It's possible to place the caret before the actual contents in a contentEditable element. This produces strange results when typing.

Reproducible: Always

Steps to Reproduce:
1. Place the caret at the beginning of the second editable div.
2. Press the up button on the keyboard
3. Notice that the caret is now before the paragraph inside the root of the div.
4. If you type you will add a new text node before the paragraph it looks really odd.
Actual Results:  
A new text node is appended before the contents.

Expected Results:  
The typed text should be added to the first element.

Comment 1

[spam]

Attachment: Testcase displaying the bug

Comment 2

[Dan POPA]

You get the same behavior by using CTRL+HOME.
Another effect of this situation is that pressing DELETE has no effect, nothing happens, FF should remove the P paragraph and keep the text content

Comment 3

[Dan POPA]

Do you refer to "before the actual contents" in the contentEditable element as "the first non white space text node"?

The selection caret appears to be in another place, but it is correctly placed in the DOM.

The selection can be placed anywhere in the DOM, even in nodes without visual representation like white space only nodes.
This is why gecko needs to add a BR when you type SPACE at the end of an element, because that last SPACE doesn't actually occupies any measurable space in the element. Gecko needs a "trailing" BR after a white SPACE to display the selection caret a SPACE away after the last visible character. Unfortunately this BR may remain inside the element, and even if it is not actually displayed as a soft break in FF, it is in IE.



Your "expected results" implies that the user would not be able to use the keyboard to put the selection before the first non-white space text node in a contentEditable element.
This can lead to the situation where the user cannot delete the first element in the contentEdtibale element because it cannot select it.


See bug 414526 for more situations like this: selection at the end or the beginning of the contentEditable element.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #2 (contenteditable root, for comparison)

Comment 5

[Mats Palmgren (inactive)]

Fwiw, patch rev. 2 in bug 512295 fixes this bug.

(In reply to comment #3)
> Your "expected results" implies that the user would not be able to use the
> keyboard to put the selection before the first non-white space text node in a
> contentEditable element.
> This can lead to the situation where the user cannot delete the first element
> in the contentEdtibale element because it cannot select it.

Yes, we should have some keyboard commands to move the caret outward when
it's placed at the beginning or end of all text.  I think that's a separate
issue though.  The behavior should be the same for root/non-root editable
elements, or designMode document.

Comment 6

[Mats Palmgren (inactive)]

Fixed by bug 512295, including a test for this bug.