Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#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:

  1. Go to http://ckeditor.swg.usma.ibm.com/
  2. CKEDITOR.instances.editor1.insertHtml('hi <a contenteditable="false">there</a> CKEditor...')
  3. 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 5 years ago by Piotrek Koszuliński

Resolution: invalid
Status: newclosed

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.

comment:2 Changed 5 years ago by Satya Minnekanti

Keywords: IBM added
Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy