1709536 - Backspace deletes the wrong element in contentEditable when directly in front of inline uneditable element

Status: NEW

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

Description

[Marijn Haverbeke]

Attachment: test.html

When the cursor is in an editable element, directly before an uneditable inline element (Selection.focusNode is the parent of the uneditable element), but with content before it as well, pressing backspace will delete the element after the cursor, instead of the content before the cursor.

When the selection is set at the same position but inside the text (focusNode is the text node, focusOffset its lenth), the problem does not occur.

Attached HTML file demonstrates the problem (on opening, it focuses an editable element and puts the cursor in the right place—if you then press backspace you see the element after the cursor vanishing).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

Unassigning myself from inactive bugs.

I think I wanted to investigate this and then completely forgot to. Masayuki, could you take a look?

Comment 3

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

At here, we give up to find editable previous things:
https://searchfox.org/mozilla-central/rev/3175fbb2342bfcdd5dcffed21a4c5a29dae1c61c/editor/libeditor/WSRunObject.cpp#1490-1495

Then, we go here:
https://searchfox.org/mozilla-central/rev/3175fbb2342bfcdd5dcffed21a4c5a29dae1c61c/editor/libeditor/HTMLEditorDeleteHandler.cpp#1643

Finally, we delete the non-editable node as an atomic content node:
https://searchfox.org/mozilla-central/rev/3175fbb2342bfcdd5dcffed21a4c5a29dae1c61c/editor/libeditor/HTMLEditorDeleteHandler.cpp#1833-1847

So perhaps, WSRunScanner::ScanPreviousVisibleNodeOrBlockBoundaryFrom shouldn't stop scanning editable things if:

• The parent of non-editable child is editable
• Its previous thing is editable (e.g., previous sibling or previous block)

However, I think that Selection is never collapsed by users' operation. I.e., this occurs only when web apps collapse selection into a non-editable node. So this is not so important for now. (Anyway, contenteditable="false" is not used widely and there must be a lot of issues.)