369981 - Caret positioned wrongly after deleting trough <div> in an iframe with designMode=on

Status: NEW

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

Description

[Tom L. Snyder]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070111 MultiZilla/1.8.3.0a SeaMonkey/1.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070111 MultiZilla/1.8.3.0a SeaMonkey/1.1

The caret disappears in an iframe with designMode=on when deleting with the
delete or the backspace-delete key through a span and div element. 

The caret positioned wrongly after deleting trough a <div> in an iframe with designMode=on

Reproducible: Always

Steps to Reproduce:
1. Open the testcase html page
2. Start at the indicated position and delete backwards through the div tag

Results:
After deleting the div the caret is not placed between the content of the line above and the trailing text but instead at the end of the trailing text line.

Reproducible: Always

Comment 1

[Tom L. Snyder]

Attachment: html testcase

Comment 2

[Tom L. Snyder]

** Please ignore the first sentence in the previous post *** ("The caret disappears in an iframe with designMode=on when deleting with the
delete or the backspace-delete key through a span and div element.")

Comment 3

[Uri Bernstein]

Confirming.

Seeing this with:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a3pre) Gecko/20070207 Minefield/3.0a3pre ID:2007020704 [cairo]

Comment 4

[Uri Bernstein]

I think that the root problem is that the two text nodes aren't joined when the div's closing tag is "deleted" (and, in practice, the remaining text is moved into the div).
This leaves us with two adjacent text nodes, the first of which eventually becomes empty.

FWIW, this is the stack trace leading to the text node on the right being inserted into the div (without being joined):
#0  nsEditor::InsertNode (this=0x2341e00, aNode=0x26cdedf0, aParent=0x2642167c, aPosition=1) at /Users/uri/mozilla/trunk/mozilla/editor/libeditor/base/nsEditor.cpp:1418
#1  0x03d4d654 in nsEditor::MoveNode (this=0x2341e00, aNode=0x26cdedf0, aParent=0x2642167c, aOffset=1) at /Users/uri/mozilla/trunk/mozilla/editor/libeditor/base/nsEditor.cpp:1743
#2  0x03cbb234 in nsHTMLEditRules::MoveNodeSmart (this=0x23d5a00, aSource=0x26cdedf0, aDest=0x2642167c, aOffset=0xbfffb694) at /Users/uri/mozilla/trunk/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp:2757
#3  0x03cbb4d4 in nsHTMLEditRules::MoveBlock (this=0x23d5a00, aLeftBlock=0x2642167c, aRightBlock=0x26cdf29c, aLeftOffset=-1, aRightOffset=7) at /Users/uri/mozilla/trunk/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp:2729
#4  0x03cbbe00 in nsHTMLEditRules::JoinBlocks (this=0x23d5a00, aLeftBlock=0xbfffb928, aRightBlock=0xbfffb92c, aCanceled=0xbfffbbe4) at /Users/uri/mozilla/trunk/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp:2628
#5  0x03cd6e3c in nsHTMLEditRules::WillDeleteSelection (this=0x23d5a00, aSelection=0x26496800, aAction=2, aCancel=0xbfffbbe4, aHandled=0xbfffbbe8) at /Users/uri/mozilla/trunk/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp:2159

Comment 5

[Cacycle]

I can reproduce this problem with Firefox 3.0.1.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Comment 6

[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.