685445 - Contenteditable=false elements in contenteditable=true elements cannot be deleted by using Backspace

Status: RESOLVED DUPLICATE of bug 1394758

(Core :: DOM: Editor, defect)

Description

[Ioana (away)]

Attachment: reduced test case

Mozilla/5.0 (Windows NT 6.0; rv:7.0) Gecko/20100101 Firefox/7.0 (b4)
Mozilla/5.0 (X11; Linux x86_64; rv:8.0a2) Gecko/20110907 Firefox/8.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110831 Firefox/9.0a1

STR:
 1. Open the attached test case.
 2. Try to delete the blue letters on the page using only backspace (each blue letter is in a different span).

Expected Results:
 The whole content of the contenteditable element can be deleted using backspace, including the nested spans.

Actual Results:
 Spans nested in a contenteditable element cannot be deleted by using backspace.

Comment 1

[Aaron Kaluszka]

From what I can tell, this bug actually has nothing to with spans. It occurs because the hosted elements have contenteditable set to false. You can replace the spans with divs, and remove the nested spans altogether and get the same behavior.

Comment 3

[Ioana (away)]

This bug is about Backspace not working on contenteditable=false elements in contenteditable=true elements at all, ever. Delete doesn't work on contenteditable=false elements in contenteditable=true elements only in one particular case - bug #685452 (a separate bug was filed for that because it is a distinct case).

Comment 4

[shaddy]

I am still experiencing this bug in Firefox 21, 2 yrs after it was originally reported.

Comment 5

[paul]

I am also still experiencing this bug in Firefox 25 and Nightly(28.0a1)

Comment 6

[Dave Jarvis]

This might be slightly off-topic, but here's a way to show that backspace does not perform as expected within contentEditable=true list items. I suspect that the bug might be related to this bug.

= Replicate =

1. Visit http://jsfiddle.net/sFSb8/
2. Position cursor to start of second list item.
3. Press backspace.

= Expected Results =

The second list item is joined with the first list item. The third list item becomes the second list item, and so on down the line. The last list item 

= Actual Results =

Backspace has no effect.

= Work Around =

1. Position the cursor to the end of the first line.
2. Press delete (this will join the first line with second line, as expected).
3. Press enter (this will split the first line and second line, resulting in what *looks* like the starting state).
4. Press backspace (now it works, but only for joining the first and second lines, which have been modified).

Firefox 26 for Ubuntu.

Comment 7

[johanneswilm]

Still here in Firefox 29, similar to https://bugzilla.mozilla.org/show_bug.cgi?id=873883 . Has contenteditable just been given up?

Comment 8

[Gerald]

If the second, from end, character is space character, pressing backspace add another spaces.

http://jsfiddle.net/w5N7C/2/

Comment 9

[keith]

after more than 3 years.. this bug still exists.
someone please update contenteditable. it was even showcased in HTML5 but its not working fine in Firefox.

Comment 10

[keith]

i found a very simple workaround but it doesnt use contentediable="false" as a child node

use input type="button instead and must be disabled. backspace and delete works fine. for the arrow keys (up|down).. add role="textbox"

http://jsfiddle.net/keithics/64d7a207/

<div contenteditable role="textbox">
backspace works! <input type="button" disabled="disabled" value="delete me" />
</div>

Comment 11

[rick]

Still an issue heren in Firefox 35+

See http://jsfiddle.net/w5N7C/2/ for a simple demo

Comment 12

[Baychae]

Still present in Firefox 36+. Crashes when I attempted to delete an embed image using backspace.

https://bugzilla.mozilla.org/show_bug.cgi?id=685445

Comment 13

[Baychae]

https://youtu.be/lNSgjrzN_kI

(In reply to Baychae from comment #12)
> Still present in Firefox 36+. Crashes when I attempted to delete an embed
> image using backspace.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=685445

Comment 14

[ffx]

Experiencing similar problems as well with Firefox 41.0.  Like others mentioned above, we have been living with this for years.

Comment 15

[slmgc]

In case anyone interested, I have found a developer
responsible for this issue, here's his comments:

https://bugzilla.mozilla.org/show_bug.cgi?id=237964#c6

"Warning, the current patch works only in the browser. Editing a document having
a contenteditable element will fail (blank page in the editor); I'm on it."

https://bugzilla.mozilla.org/show_bug.cgi?id=237964#c7

"For the purpose of this bug, I have blocked caret movement from one editable
frame to a non-editable one, outside of caret browsing mode of course. The ideal
solution would be a loop to find the nearest editable frame in the requested
direction but I have no time right now to do that, it's a significant change in
nsSelection."

Comment 17

[Alper Çakan]

Still experiencing the problem with 58.0.1

Comment 18

[Oleg Pnk]

Hello from 2018 (v64.0). Bug still reproduce.

Comment 19

[Ben]

v66.0 - still reproducible. This is marked as a duplicate and resolved.

I cannot find an open bug related to this issue. Can we re-open this (as the earliest reference to this bug) so that the issue is tracked?

Comment 20

[jeff]

We are still seeing this issue in FF 72.0.1 (Mac); example: https://jsfiddle.net/063bmd4u/1/.

Comment 21

[yair even or]

(In reply to jeff from comment #20)

We are still seeing this issue in FF 72.0.1 (Mac); example: https://jsfiddle.net/063bmd4u/1/.

I am having the same annoyances which greatly affects a plugin of mine which is used by thousands (https://www.npmjs.com/package/@yaireo/tagify)

As Jeff showed, this is still happens, and also there are caret issues (it isn't shown)

Comment 22

[rburnie]

Bug still exists in Firefox mac 78.0.1 (a colleague said she sees in on windows)
Even if you inspect a content editable field, edit its html and then add <span contenteditable="false">hello?</span> it wont be deleteable.

Note: we have notice that contenteditable="false" elements added while focussed are able to be deleted, but if you blur and refocus or they pre exist before focus the are not able to be deleted.

Comment 23

[rburnie]

Update... I also noticed that if i add a <span contenteditable="true"></span> after the contenteditable="false" el i cant delete that the act of deleting the contenteditable="true" one seemed to make it possible to delete the contenteditable="false" one.

So thats how I will be "fixing" this issue currently, which is awful :(

Comment 24

[ehonkulus]

This bug has been reported as early as ~10 years ago and had been marked multiple times as "resolved". However, in mid September year 2020, it is not resolved and is in fact still an active bug.

As others have stated, when building a custom input using "contenteditable=true", if you inject an inline html element e.g. a <span> with <span contenteditable="false">, only in mozilla firefox can you not delete this element. When the caret reaches the right side of the inline <span>, it will both vanish (you can no longer see it), and you cannot delete the inline element. In all other browsers the element will be deleted with no noticeable glitches.

Is Mozilla working on this bug? Given that "contenteditable" is an increasingly common feature, and many popular javascript frameworks use it, I am surprised this bug still exists.

A simple google "firefox contenteditable backspace" will reveal numerous postings about this issue across many javascript projects, bug reports, and stackoverflows.

Please update us, thank you.

Comment 25

[Emilio Cobos Álvarez [:emilio]]

Commenting on closed bugs is unlikely to get much attention. If something regresses, it's better to file a new bug. I opened bug 1665167 for that, as I can trivially reproduce.

Comment 26

[ehonkulus]

ok great thank you Emilio!