439808 - Backspace & Delete doesn't work correctly in contenteditable inline elements (such as spans) nested in another inline element

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Robbie Paplin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: 

Backspace & Delete key doesn't work correctly in contenteditable DIV for all cases. Specifically, when the caret immediately precedes or follows a <SPAN contenteditable="false"> node, the Backspace & Delete key events are being ignored. Since you can select the span nodes and remove them, Backspace & Delete key should also remove the entire span node.

Reproducible: Always

Steps to Reproduce:
Navigate to the attached document...

1.  Set the caret to the semicolon between Peyton Manning & Matt Hasselbeck in the To... field (via mouse click)
2. Press the Delete key repeatedly until the delete key stops working
3. Note where the caret stops moving (before Matt Hasselbeck)
4. Set the caret to the semicolon between Peyton Manning & Matt Hasselbeck in the To... field (as you did in step 1)
5. Press the Backspace key repeatedly until the backspace key stops moving
6. Note where the caret stops moving (after Peyton Manning)

Actual Results:  
At step 3, the delete key event stops working before it hits the ending of the contenteditable DIV.

At step 6, the backspace key event stops working before it hits the beginning of the contenteditable DIV. 

Expected Results:  
At step 3, the delete key should keep deleting until the caret is at the end of the contenteditable DIV (continue until it deletes Matt Hasselbeck & Eli Manning).

At step 6, the backspace key should keep deleting until the caret is at the beginning of the contenteditable DIV (continue until it deletes Tom Brady & Peyton Manning).

The span nodes & text nodes should keep getting removed until the caret is at the beginning or ending of the contenteditable div. After reaching the div boundary, additional delete or backspace key events should be ignored (like a <input type=text> or <textarea> element would act).

On IE 7 for Windows it works as expected.
On Safari 3.1.1 for Macintosh / Windows it works as expected (unless the span node is at a DIV boundary - currently a known Webkit bug).
If you create a non collapsed selection, which contains the span nodes, and then press Delete or Backspace it works as expected.

Comment 1

[Robbie Paplin]

Attachment: Backspace & Delete doesn't work correctly in contenteditable DIV for all cases

Comment 2

[Sharief Shaik]

I too have the exact problem with my contenteditable DIV set to true with inner "span", "a" elements having attribute contenteditable=false. The backspace couldn't delete the elements on left side of cursor having property contenteditable=false. This works fine in all major desktop browsers except firefox. Strange! Actually tried on FF3.5+

Comment 3

[Sidney San Martín]

Attachment: My own minimal test case for this issue

454191, 458182, 546662, and 571694 all seem to be dupes of this issue. It's dang annoying.

Comment 6

[(no longer active)]

Note to myself: see bug 458182 comment 2.

Comment 9

[Alex Cabal]

I ran in to this bug too, but unfortunately only after deploying my web app live.  In my particular situation it's an edge case but happens enough to be a problem to some of my users.

I found that a workaround is to wrap the contenteditable span in a p tag styled with display: inline.  That preserves the inline appearance of the contenteditable span, but Firefox still lets you delete text like you should.

So this is a minimal case with workaround would look like:
<div><span><p style="display: inline;"><span contenteditable="true">some text that you can now delete</span></p></span></div>

I hope this bug can get fixed soon so I can get rid of this awful workaround code.  It's strange having to target FF over IE for a change!

Comment 10

[Mathias Bynens]

(In reply to comment #9)
> I found that a workaround is to wrap the contenteditable span in a p tag
> styled with display: inline.  That preserves the inline appearance of the
> contenteditable span, but Firefox still lets you delete text like you should.
> 
> So this is a minimal case with workaround would look like:
> <div><span><p style="display: inline;"><span contenteditable="true">some
> text that you can now delete</span></p></span></div>

Instead of wrapping the <span> in a <p> with `display: inline`, you could also just replace the <span> with it:

<div><span><p style="display: inline;" contenteditable="true">some text that you can now delete</p></span></div>

Comment 11

[(no longer active)]

Alex, can you please share a link to the web app in question, so that I can verify if you're indeed hitting the same underlying bug, and if so, fix it soon?

Comment 12

[Aaron Kaluszka]

This has been driving me and users crazy on an internal webapp as well. It's basically the same as the reduced testcase, except the span is generated by Javascript. At some point, this problem got worse such that delete and backspace don't work in any position. The trick to editing the field is to select the text you want to delete before deleting it. That still doesn't work for the very last character, however.

Comment 13

[diana chow]

Here's a repro case I created on jsfiddle:

http://jsfiddle.net/dhchow/BZMVg/2/

You can't backspace the colored elements to remove them. But you can select them and delete them. Note the style="display:inline;" in the second div didn't work either for me.

Comment 14

[Mathias Bynens]

Minimal test case: data:text/html;charset=utf-8,<p><i><i contenteditable>edit me</i></i>

Comment 15

[Mathias Bynens]

(In reply to comment #14)
> Minimal test case: data:text/html;charset=utf-8,<p><i><i
> contenteditable>edit me</i></i>

Note that if you remove the opening <p> tag everything’s peachy. This bug title should probably be changed to something like “Backspace & Delete doesn't work correctly in contenteditable inline elements (such as spans) nested in another inline element inside a block-level element.”

Comment 16

[(no longer active)]

Attachment: Patch (v1)

The problem is that nsHTMLEditRules::CheckForEmptyBlock doesn't check to make sure the empty block it finds is in fact editable, so it might fail, causing nsHTMLEditRules::WillDeleteSelection to bail out.

Comment 17

[(no longer active)]

Alex, please feel free to test the builds here <https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-27de71545ed1/> and see if they have fixed the bug for you.

Comment 18

[Mathias Bynens]

I can confirm the `try-macosx64` build fixes the issue. (There are still other contenteditable issues though, for example selected text can’t be deleted, but there are separate bug tickets for that.)

Thanks, Ehsan!

Comment 19

[(no longer active)]

(In reply to comment #18)
> I can confirm the `try-macosx64` build fixes the issue. (There are still
> other contenteditable issues though, for example selected text can’t be
> deleted, but there are separate bug tickets for that.)

Please feel free to either file new bugs for those other issues, or point me to the existing bugs.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 542799 [details] [diff] [review]
Patch (v1)

Review of attachment 542799 [details] [diff] [review]:
-----------------------------------------------------------------

Comment 21

[Alex Cabal]

The try-win32 build seems to have the issue partially fixed.  If I do ctrl+a on the span or highlight all of the contents with the mouse and press backspace, text still does not get deleted.  (Though a partial highlight does get deleted.)  Not sure if this is related to this bug or if it's a different one.  Either way thanks Ehsan!

Comment 22

[Mathias Bynens]

(In reply to comment #19) 
> Please feel free to either file new bugs for those other issues, or point me
> to the existing bugs.

See bug #389348.

Comment 23

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/bda80dd7467d

Comment 24

[(no longer active)]

(In reply to comment #21)
> The try-win32 build seems to have the issue partially fixed.  If I do ctrl+a
> on the span or highlight all of the contents with the mouse and press
> backspace, text still does not get deleted.  (Though a partial highlight
> does get deleted.)  Not sure if this is related to this bug or if it's a
> different one.  Either way thanks Ehsan!

Please file a new bug for that.

Comment 25

[Aaron Kaluszka]

This isn't quite fixed for me on the trunk builds (Win32 and Win64). Delete still doesn't work on the last character in the testcases, though backspace now does.

Comment 26

[(no longer active)]

(In reply to comment #25)
> This isn't quite fixed for me on the trunk builds (Win32 and Win64). Delete
> still doesn't work on the last character in the testcases, though backspace
> now does.

Can you please file a new bug about that too?

Comment 27

[Aaron Kaluszka]

Bug 670807 filed for comment 25 and bug 670809 filed for comment 21 (and related cases).

Comment 28

[Ioana (away)]

Verified on:
Mozilla/5.0 (Windows NT 6.0; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110831124126

To verify this fix I used the attachments in comment #1 and comment #3.

When using the attachment from comment #3, all the text from the editable content can be deleted both using delete and backspace (bug #670807 does reproduce though).

When using the attachment from comment #1 the issue is still partially reproducible:
1. Backspace doesn’t work at all on the spans in the “To” field.
2. When using delete the last span cannot be deleted (bug #670807).
3. When placing the caret in front of the first span in the “To” field using delete you cannot delete anything in that field - this issue only reproduces before doing anything else on the page. If the user simply moves the caret one then places the caret in front of the first span, the deleting works fine.

These 3 issues reproduce on multiple OSs:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0

Please let me know if you believe I should reopen this bug because of issue #1 or if you want me to log another bug for issue #3.

Comment 29

[Martijn Wargers (dead)]

Please file bug for every issue that you are still seeing.

Comment 30

[Aaron Kaluszka]

Also, please retest on a nightly build as more bugs were fixed after Firefox 7 branched.

Comment 31

[Ioana (away)]

Rested on the last nightly build - all the issues mentioned in my previous comment are reproducing:
 - bug #670807 was reopened;
 - bug #685445 was filed for the 1st issue;
 - bug #685452 was filed for the 3rd issue.

Closing this bug since the remaining issue are treated in different bugs.