832731 - Caret positioning wrong after inserting<br> in contentEditable

Status: NEW

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

Description

[John]

Attachment: bug.html

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!

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

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.

Comment 2

[John]

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

Comment 3

[John]

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.

Comment 5

[Danilo B]

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

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sigh, the spec does not declare how the range is modified after calling Range.insertNode().

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.