Created attachment 559066 [details] 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.
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.
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).
I am still experiencing this bug in Firefox 21, 2 yrs after it was originally reported.
I am also still experiencing this bug in Firefox 25 and Nightly(28.0a1)
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.
Still here in Firefox 29, similar to https://bugzilla.mozilla.org/show_bug.cgi?id=873883 . Has contenteditable just been given up?
If the second, from end, character is space character, pressing backspace add another spaces. http://jsfiddle.net/w5N7C/2/
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.
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>
Still an issue heren in Firefox 35+ See http://jsfiddle.net/w5N7C/2/ for a simple demo
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
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
Experiencing similar problems as well with Firefox 41.0. Like others mentioned above, we have been living with this for years.
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."