Repository navigation
Nested editing hosts do not need to be wrapped in insertParagraph #490
Description
Activity
- added 2 commits that reference this issue
on Sep 3, 2025 @gmta could you create a test case for your scenario? We tried to reproduce this during the meeting and got different results.
This is similar to the test case I used to write the fix for Ladybird:
<!DOCTYPE html> <div id="a" contenteditable>foo <div id="b" contenteditable>bar</div></div> <pre id="output"></pre> <script> getSelection().setBaseAndExtent(b.firstChild, 0, b.firstChild, 1); document.execCommand('insertParagraph'); output.append(a.outerHTML); </script>
FIrefox:
<div id="a" contenteditable="">foo <div id="b" contenteditable=""><br></div><div contenteditable="">ar</div></div>
Chrome and Safari:
<div id="a" contenteditable="">foo <div id="b" contenteditable=""><br></div><div id="b" contenteditable="">ar</div></div>
Ladybird (pre-fix):
<div id="a" contenteditable="">foo <div id="b" contenteditable=""><div><br></div><div><div>ar</div></div></div></div>
Ladybird (including ad-hoc change to "is editing host"):
<div id="a" contenteditable="">foo <div id="b" contenteditable=""><br></div><div contenteditable="">ar</div></div>
Note that this last output is identical to Firefox' output. Also note that Chrome and Safari seem to duplicate the
idattribute, which arguably seems like worse behavior.I think that the editing host definition is wrong. The definition does not assume that
contenteditable="true"andcontenteditable="plaintext-only"are nested. I believe that it's not an editing host if an editable element parent is also editable.TPAC 2025:
Ollie: Postpone due to editor being in other meeting.
When performing the action for
insertParagraph, step 11 asks to check if the container is not editable:editing/docs/execCommand/index.html
Lines 13580 to 13584 in b9fbe88
This is not how it currently works in both Chrome and Firefox for the following case:
If
insertParagraphis run while a selection exists inside the inner editing host, a new container is created to wrap the contents in. This should not be necessary, and Chrome and Firefox both use the existing inner editing host as the container.The behavior seems to be more accurately reflected by:
If the container is not editable and the container is either not an editing host, or its parent is neither editable nor an editing host, ...An alternative approach could be to change the "is editing host" logic to exclude elements with contenteditable set to true or plaintextonly that are children of an editable node or an editing host, which is the approach I took for Ladybird.