Bug 221265

Summary:	[GTK] insertHTML command with selection overwrite can replace too much text
Product:	WebKit	Reporter:	Milan Crha <mcrha>
Component:	WebKitGTK	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	bugs-noreply, nekohayo
Priority:	P2
Version:	Other
Hardware:	Unspecified
OS:	Unspecified

Description Milan Crha 2021-02-02 09:13:10 PST

Coming from a downstream bug report:
https://gitlab.gnome.org/GNOME/evolution/-/issues/1339

The "insertHTML" command, when replacing a selection, can cut too many letters (one more than expected) and replace it with `&nbsp;`.

Steps to reproduce:
a) run: MiniBrowser --editor-mode
b) open the inspector and paste into the console this command:

   document.body.outerHTML="<body style=\"-webkit-line-break: after-white-space;\"><div>aaaaaaaa aa popular belief, aaaaa aaaaa aa aaa aaaaaa aaaaaa aaaa. aa aaa aaaaa aa a aaaaa aa aaaaaaaaa aaaaa aaaaaaaaaa aaaa aa</div><div class=\"-x-evo-signature-wrapper\"><span class=\"-x-evo-signature\" id=\"none\"></span></div></body>"

c) then paste these two commands - the first selects the text, the second replaces it (when pasted separately the selection is discarded, which doesn't reproduce the bug):

   document.getSelection().setBaseAndExtent(document.body.firstElementChild.firstChild, 12, document.body.firstElementChild.firstChild, 26); document.execCommand("insertHTML", false, "<a href=\"https://\">popular belief</a>")

   The command basically selects the "popular belief" text and replaces it with a link. Use Undo to see what had been selected before the "insertHTML" command execution.

Actual outcome:

   ... &nbsp;<a ...>popular belief</a>&nbsp; aaa...  (instead of the coma, there's an '&nbsp;'

Expected outcome:

   ... except of the &nbsp; there's left the comma

Observations:

1) it doesn't matter whether it's a comma or a letter at the end of the selection; selecting one letter less will reproduce the problem too, but cutting the 'f' letter instead

2) the length of the <div> matters - using one letter less (cut the last `a`) will not reproduce the bug

3) not using "-webkit-line-break: after-white-space;" will not reproduce the bug

4) shifting the selection start more to the left will not reproduce the bug (like from 11 to 26, instead of 12 to 26)