#13221 closed Bug (invalid)
Incorrect ranges when trying to delete a contentEditable element
Reported by: | Inga | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | General | Version: | |
Keywords: | IBM | Cc: | Satya Minnekanti |
Description
When you set the attribute contentEditable=false in an HTML element within the element and try to remove it with just one keystroke, CKEditor creates a temporary div and moves to it on the first keystroke (ie backspace) and then will delete the element in the second one. That is not the expected behaviour - user should require only one keystroke to delete the element
How to reproduce:
- Go to http://ckeditor.swg.usma.ibm.com/
- CKEDITOR.instances.editor1.insertHtml('hi <a contenteditable="false">there</a> CKEditor...')
- CKEDITOR.instances.editor1.document.on('keydown', function(evt) { try{console.log(evt.sender.getSelection().getRanges()[0].endContainer.getName())}catch(e){} })
as you can see when you navigate right before the contenteditable element using the arrow keys and then hit backspace key to delete element, the cursor disappears and a temorary markup is added in the editor right after the </p>
Change History (2)
comment:1 Changed 10 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 Changed 10 years ago by
Keywords: | IBM added |
---|
This is the expected behaviour. Note that non-editable elements are supported only in forms of widgets. When you press a backspace before a widget it gets focus (what is visible correctly). Only pressing backspace/delete on a focused widget deletes it. This is an intentional behaviour because it better indicates what will be deleted. Of course it was our own decision to so we're open to discuss it, but non user complained so far.