Open
Bug 369981
Opened 17 years ago
Updated 3 years ago
Caret positioned wrongly after deleting trough <div> in an iframe with designMode=on
Categories
(Core :: DOM: Editor, defect, P5)
Core
DOM: Editor
Tracking
()
NEW
People
(Reporter: tools, Unassigned)
References
Details
Attachments
(1 file)
696 bytes,
text/html
|
Details |
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
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
** 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•17 years ago
|
||
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]
Assignee: nobody → selection
Status: UNCONFIRMED → NEW
Component: View Source → Selection
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: view.source
Hardware: PC → All
Version: unspecified → Trunk
Comment 4•17 years ago
|
||
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
Assignee: selection → nobody
Component: Selection → Editor
Updated•17 years ago
|
QA Contact: editor
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•3 years ago
|
||
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.
Severity: normal → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•