Closed Bug 439808 Opened 16 years ago Closed 13 years ago

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

Categories

(Core :: DOM: Editor, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla7

People

(Reporter: rpaplin, Assigned: ehsan.akhgari)

References

Details

(Keywords: testcase)

Attachments

(3 files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Flags: blocking1.9.1?
Flags: blocking1.9.1? → wanted1.9.1+
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+
454191, 458182, 546662, and 571694 all seem to be dupes of this issue. It's dang annoying.
Assignee: nobody → ehsan
Whiteboard: [post-2.0]
Summary: Backspace & Delete doesn't work correctly in contenteditable DIV for all cases → Backspace & Delete doesn't work correctly in contenteditable inline elements (such as spans) nested in another inline element
Note to myself: see bug 458182 comment 2.
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!
(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>
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?
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.
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.
Minimal test case: data:text/html;charset=utf-8,<p><i><i contenteditable>edit me</i></i>
(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.”
Attached patch Patch (v1)Splinter Review
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.
Attachment #542799 - Flags: review?(roc)
Whiteboard: [post-2.0]
Alex, please feel free to test the builds here <https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-27de71545ed1/> and see if they have fixed the bug for you.
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!
(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 on attachment 542799 [details] [diff] [review]
Patch (v1)

Review of attachment 542799 [details] [diff] [review]:
-----------------------------------------------------------------
Attachment #542799 - Flags: review?(roc) → review+
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!
(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.
http://hg.mozilla.org/mozilla-central/rev/bda80dd7467d
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
(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.
Flags: in-testsuite+
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.
(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?
Bug 670807 filed for comment 25 and bug 670809 filed for comment 21 (and related cases).
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.
Please file bug for every issue that you are still seeing.
Also, please retest on a nightly build as more bugs were fixed after Firefox 7 branched.
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: