381165 - Caret positioning incorrect with LI elements added to DOM

Status: NEW

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

Description

[Mathieu Fenniak]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

After modifying the DOM for an editable contentDocument and adding some LI elements, the caret positioning appears incorrectly.  Moving around the document will place the caret to the left (before) the bullets, or right-aligned, but not directly to the right of the bullet as would be expected.

This bug does not appear if execCommand("inserthtml", ...) is used to create the LI elements, nor does it appear if the document starts with the LI elements in it.  It seems to only appear when the LI elements are added to the body after the page load, by normal createElement/appendChild means.

Will attach testcase & images of results.

Reproducible: Always

Steps to Reproduce:
1. Load test case (to be attached).
2. Click to focus on the editable content.
3. Move the cursor down, from it's original position at the top of the document, by pressing the down arrow key twice.  Observe actual results 1.
4. Move the cursor down further, by pressing the down arrow key twice more.  Observe actual results 2.
Actual Results:  
1. Cursor is to the left/overtop of the bullet.
2. Cursor is to the far-right of the editable content.

Expected Results:  
1. Cursor should be immediately to the right of the second bullet.
2. Cursor should be immediately to the right of the third bullet, or perhaps on a line below it, but not to the far right of it.

Tested with latest daily build after seeing possibly related bugs such as #368893 that have been fixed.  Behavior is no different than FF 2.0.0.3.

Comment 1

[Mathieu Fenniak]

Attachment: test case

Comment 2

[Mathieu Fenniak]

Attachment: image of results from test procedure

Comment 3

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 Minefield/3.0a5pre ID:2007051504 [cairo]
I see this on trunk too.

Comment 4

[Martijn Wargers (dead)]

I guess the patch in bug 389321 might fix this, or at least change things.

Comment 5

[Jens Stutte [:jstutte]]

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

If you have reason to believe this is wrong, please write a comment and ni :jstutte.