Bug 93583 – Select/insertHTML at element boundaries inserts content in the wrong place

• Status: NEW
• Component: HTML Editing

[David Gatwood]

1.  Set document body to contentEditable.
2.  Create a range and add it to the window selection.
3.  range.setStartAfter(document.body.lastChild);
4.  document.execCommand("insertHTML", false, "content to insert")

Notice that the content gets inserted *inside* the last element even though the insertion point is explicity *after* the last element.  This can't be correct behavior.  Firefox behaves as I would expect (inserting the data outside the last element).

Example attached.

[David Gatwood]

Created attachment 157395 [details]
Sample script that demonstrates the bug.

[David Gatwood]

It also fails if you try to replace the entire contents of a node in lots of spectacular ways.  For example, the second script I'm attaching, inserthtmlWholeBody.html, makes a copy of document.body.innerHTML, then uses execCommand's insertHTML to replace the entire body with its former contents.  This works correctly in Firefox (the body's contents are identical after the operation).  However, in Safari/WebKit, you get nodes nested inside other nodes that should not exist.

[David Gatwood]

Created attachment 157397 [details]
Second test case that nukes the entire body of a node and replaces it (unsuccessfully)

[Ahmad Saleem]

Attached test cases produces "fail" results for Safari 15.4 and Chrome Canary 104 but it shows as "pass" for Firefox Nightly 102.

[Ryosuke Niwa]

This is the expected behavior as of now since we canonicalize positions before applying editing operations.

[Ahmad Saleem]

If it is aligned with spec, should we close this? or is something needed here? Thanks!

[David Gatwood]

If it is aligned with the spec, then the spec is badly broken.  The current behavior makes a lot of useful editing behavior impossible, and that's not good.

For background on this, I was trying to construct some semi-WYSISYG structured XML editors (for writing novels and screenplays) using WebKit, and I just plain gave up because I couldn't insert nodes inside empty elements, I couldn't reliably insert nodes between elements, I couldn't put the insertion cursor between elements even with element boundaries visible, etc.

If element boundaries are visible (with ::before and ::after pseudo-elements), then all of these locations (between elements, inside elements, etc.) are visually distinct locations in the document, and should absolutely not be canonicalized into a single position.

And the same is true for buttons.  No reasonable person would expect inserting content after a button to insert it into the button.  The inside of a button is visually distinct from the outside of a button.

So the current canonicalization behavior makes no sense.  It may be expected based on the way things are written right now, but it certainly isn't expected.  :-)

[Ryosuke Niwa]

(In reply to Ahmad Saleem from comment #6)
> If it is aligned with spec, should we close this? or is something needed
> here? Thanks!

There isn't really a spec to speak of here. Fixing this bug most likely require https://bugs.webkit.org/show_bug.cgi?id=220514 to be resolved first.

[Ahmad Saleem]

This one still fails with Live Range Selection API on WebKit ToT (260520@main). Changing to ‘New’.