Bug 131536 – It shouldn't be possible for users to place the cursor outside of block tags in a contenteditable that only contains block tags

• Status: NEW
• Component: HTML Editing

[Le Roux Bodenstein]

Here's a test case:

1. Browse to http://codepen.io/lerouxb/pen/JGIcK
2. Hit select all, then delete or backspace.
OR drag-select all the text, then hit backspace.
OR place the cursor at the end of the second paragraph, then hold down backspace
3. Type some text.

I expect to eventually end up with an empty paragraph (<div class="editable" contenteditable><p></p></div>), but I end up with <div class="editable" contenteditable></div> and then the cursor is directly inside the contenteditable div, causing the user to insert text outside of a block text tag. ie. outside any paragraph, quote, heading, list, etc and inside a meaningless container. (Hilighted as red)

If you have two paragraphs and you backspace past the start of the second one, then the two get joined instead of the second paragraph just being removed and the cursor being placed after the first one and directly inside the div / container.

This indicates to me that at some stage whoever implemented backspace did have the right idea (keep the cursor inside clean html like a block tag if that's what you started with), it just isn't consistently implemented at the edge cases.

I just want that behaviour to be consistent. Or at least a way to tell the contenteditable that that's what I want.

I also submitted this to chrome (https://code.google.com/p/chromium/issues/detail?id=362492) and to firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=995144). All three browsers tend to have their own quirks around backspace, delete and enter.

[Ahmad Saleem]

This is marked as "RESOLVED WONTFIX" in 2017 by Chromium / Blink and proposed that "Selection API" is more intended usercase fo the user rather than contenteditable.

https://bugs.chromium.org/p/chromium/issues/detail?id=362492#c14