Open
Bug 832731
Opened 12 years ago
Updated 2 years ago
Caret positioning wrong after inserting<br> in contentEditable
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
NEW
People
(Reporter: john.foreign, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: testcase, Whiteboard: [h2review-noted])
Attachments
(1 obsolete file)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130104151925
Steps to reproduce:
In the attached demo file, position the cursor somewhere in the red-bordered div and press ctrl-Enter. This is caught by JS and a <br> is inserted programatically, with collapse(false) collapsing the range to the end.
Actual results:
The caret was positioned at the end of the first line before the line break.
Expected results:
Caret should be at the start of the second line. (This is what happens if you just press Enter, where the default event handling inserts <br>) A workaround is to insert <br><span></span>, then collapse the range (to the end of the span) then delete the span. Not very elegant!
Updated•12 years ago
|
Component: Untriaged → Editor
Product: Firefox → Core
Updated•12 years ago
|
Attachment #704308 -
Attachment mime type: text/plain → text/html
Comment 1•12 years ago
|
||
I see the Issue back to Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.19) Gecko/2010031422 Firefox/3.0.19 ID:2010031422.
Doesn't work in Chrome/MSIE10 either since nothing happens when you CTRL + ENTER there.
Keywords: testcase
...or with MSIE 8/9 since the DOM functions don't work, but pasteHTML() can be used instead to insert <br>, and the caret is then positioned as expected.
Chrome seems to report Enter as evt.keyCode == 10 instead of evt.keyCode == 13. If you change the keypress handler to take this into account, Chrome behaves like Firefox.
Updated•6 years ago
|
Updated•6 years ago
|
Blocks: editor-blink-compat
This bug is quite a problem when implementing rich text editors using contenteditable elements. Since the original report is already 6 years old, it would be fantastic if it could get prioritized.
Comment 6•5 years ago
|
||
Sigh, the spec does not declare how the range is modified after calling Range.insertNode()
.
Updated•5 years ago
|
Attachment #704308 -
Attachment is obsolete: true
Comment 7•5 years ago
|
||
Ah, it's completely same behavior if you use non-selection range:
https://jsfiddle.net/d_toybox/uhr7dt9s/20/
And also even if you use selection, it's also completely same behavior:
https://jsfiddle.net/d_toybox/uhr7dt9s/25/
However, doing it in keydown
or keypress
event listener, it's sometimes reproduced. I guess that it depends on interlinePosition
settings.
Updated•5 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Updated•4 years ago
|
Whiteboard: [h2review-noted]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•