Bug 105323 – when contentEditable=true inside contentEditable=false inside contentEditable=true, backspace behavior is wrong

• Status: UNCONFIRMED
• Component: HTML Editing

[Johannes Wilm]

A contenteditable=false element inside a contenteditable=true element can be delted by hitting backspace. However, if there is a contenteditable=true inside the contenteditable=false, then this is not working.

See attached test file.

[Johannes Wilm]

Created attachment 179974 [details]
a testcase of contenteditable=false inside contenteditable=true

[Johannes Wilm]

Created attachment 182773 [details]
test case showing contenteditable=false inside contenteditable=true

this case shows three different cases and how they are handled differently by the delete command:

Try to delete the three contenteditable=false areas using backspace/del, and the results are very different -- one can be deleted without problems, one spills its contents into the outer container, and the last one cannot be deleted at all.

[Enrica Casucci]

(In reply to comment #2)
> Created an attachment (id=182773) [details]
> test case showing contenteditable=false inside contenteditable=true
> 
> this case shows three different cases and how they are handled differently by the delete command:
> 
> Try to delete the three contenteditable=false areas using backspace/del, and the results are very different -- one can be deleted without problems, one spills its contents into the outer container, and the last one cannot be deleted at all.

The mixed editablity scenarios are very tricky and our support is definitely not complete.
Part of the reason is that there are many situations in which it is unclear what the right thing to do is.
Not much progress has been done in this area, since it has always been considered an uncommon scenario and the reason is that we have seen very few bugs in this area.
I believe WebKit handles fairly well documents containing editable and non editable portions, the problems appear when we nest them.
I don't know the scope of what you're trying to accomplish, but maybe you can consider an approach where you avoid nested editable/non-editable elements. I'll be happy to provide any guidance in this area.

[Johannes Wilm]

Hi,
and thanks for the advice.

The places where I already use noneditable parts inside editable parts is when adding elements to the text flow, that are autogenerated (the writer presses a button). For example, imagine this:

<p>London, UK, <span class="timepoint" data-jstime="738039459093" contenteditable="false">Oct. 2, 2012, 2:34pm GMT<span>: The Queen announced an extra allowance on cat food this morning.</p>

The time stamp is something the writer can enter by clicking a button. He can subsequently remove it again by deleting it in the text, either by selecitng it or by hitting the backspace key while the cursor is directly behind it. 

In this case, Webkit works fine already.

However, when going to the more complicated case of a nested editable part, it instide kind of knocks the back wall out. In this example: http://sourcefabric.github.com/BookJS/test.html scroll to the fifth page (the one with the headline "Some text part"). The footnotes on that page are created in this nested manner. If you move the cursor behind one of the footnote references in the main text and hit "Backspace", you would imagine that the footnote reference as well as the entire footnote would disappear. This would happen if Webkit would delte the entire non-editable element as it does in the case above. Instead it is as if the ack wall is being knocked out.

As I understand it, if changed, it would follow this logic:

"UAs should offer a way for the user to delete text and elements, including non-editable descendants, e.g. as the default action of keydown events whose identifiers are 'U+0008' or 'U+007F'."  

http://www.w3.org/TR/2008/WD-html5-20080610/editing.html

If you have suggestions as how to achieve this in another way, please let me know!

[Johannes Wilm]

One question: I understand that you guys don't plan on fixing/standardizing this behavior in the short-term due to resource constraints. But are you guys also opposed to the idea that others take it upon themselves to try to fix this? editabel and non-editable should work in a nested way the way I read the specifications that have been released about this the last few years, right?

[Enrica Casucci]

(In reply to comment #5)
> One question: I understand that you guys don't plan on fixing/standardizing this behavior in the short-term due to resource constraints. But are you guys also opposed to the idea that others take it upon themselves to try to fix this? editabel and non-editable should work in a nested way the way I read the specifications that have been released about this the last few years, right?

WebKit is an OpenSource project and anyone is welcome to contribute. The changes go through the normal review process as any contribution to the project and once they have been reviewed they can be checked in.
Please remember that this is one of the most complicated areas of the system and making changes is a non trivial task even for developers that have very experienced with WebKit.
I'll be happy to review and provide guidance if you decide to tackle this.