717789 - [Tracking] ContentEditable editing actions should not change the attributes of the editing host

Status: REOPENED

(Core :: DOM: Editor, defect, P5)

Description

[Tom Robinson]

If execCommand() would result in applying a style to the entire contents of an editing host, Firefox changes the style attribute of the editing host.

This is no good!

ContentEditable should mean that the *content* of an element is editable, not the element itself.

Rich text editors should not need to fish around in an editing host's style attribute to see if execCommand() has changed it. All editing changes should be reflected in the editing host's innerHTML.

Test case:

<div id="editor" contenteditable="true" style="background-color:pink">Make me bold</div>
<button onclick="document.execCommand('bold', false, '')">Bold</button>
<button onclick="alert(document.getElementById('editor').innerHTML)">innerHTML</button>

Select all of the text "Make me bold", then click the [Bold] button.
The text becomes bold.
Now click the [innerHTML] button.

Expected result:
Any of these three results would be acceptable.
   <b>Make me bold</b>
   <strong>Make me bold</strong>
   <span style="font-weight:bold;">Make me bold</span>

Actual result in Firefox 9.0.1:
   Make me bold

Firebug reveals that the editing host itself was changed:
<div contenteditable="true" style="background-color: pink; font-weight: bold;" id="editor">Make me bold</div>

Comment 1

[(no longer active)]

I think the new editing spec mostly agrees with this, right?

Comment 2

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

It explicitly tries to guarantee it:

"""
Note: Barring bugs, the algorithms here will not alter the attributes of a non-editable element; will not remove a non-editable node from its parent (except to immediately give it a new parent in the same editing host); and will not add, remove, or reorder children of a node unless it is either editable or an editing host. An editing host is never editable, so authors are assured that editing commands will only modify the editing host's contents and not the editing host itself.
"""
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#in-the-same-editing-host

Of course, there may be spec bugs.  But I always try to check for editability before modifying attributes.

Comment 3

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

This should be fixed by the patches for bug 746515.  The given test-case now works for me in the latest nightly on Ubuntu: as-is it produces <b>, with document.execCommand("stylewithcss", false, true) it produces <span style="font-weight: bold">.  Please file new bugs if you find any other cases where editing hosts are modified.

Comment 4

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

Oh, tracking bug -- I'm not very awake.  Well, if you find anything else then file a new bug and make it block this, then.

Comment 5

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.