Bug 114041 – Selection truncated after .splitText call

• Component: HTML Editing
• Status: NEW

[Nathan Vander Wilt]

Created attachment 196649 [details]
Simple demo showing the issue

When a text node within a selection is divided into two nodes by a call to .splitText, the window's selection is changed. This does not happen in Firefox or IE9 and seemingly should not happen according to the relevant specs (e.g. http://dom.spec.whatwg.org/#concept-text-split).

To reproduce (see attached demo source as well):
1. Select some text within a text node (programmatically or via HID)
2. Programmatically split one of the text nodes

Expected results:
Original selection is still displayed in user interface.

Actual results:
Selection gets truncated!

Workaround:
Any range object referenced before the splitText call is correctly updated; if a this stored range is set the display does update. However in practice I am seeing as-yet undiagnosed issues with this workaround if the user is dragging from right to left to select the text.

[Nathan Vander Wilt]

Created attachment 196652 [details]
Tweak the demo to show weird multiple selection effects

Things get even stranger: it appears that the bug doesn't so much "truncate" the selection as it is *not* selecting the new text node. I.e. the result can be a multiple-selection looking thing that can't be represented by the single-selection-only W3C standard.

What's even weirder is that this broken multiple selection effect persists even after calling `.selectAllChildren(parent)` on the selection after the text is split. See new attachment — click on the button repeatedly to randomly split text and the selection soon starts getting "holes" in it between a previous split and the most recent one.

[Ahmad Saleem]

I am able to reproduce this bug using "tweak" demo where clicking "button" multiple time show that the selection does get dropped and there are patches of text not selected while it is not the case in Chrome Canary 110 and Firefox Nightly 109.

While in simple "Demo", Chrome Canary 110 and Safari 16.1 behave same and update selection to just "Here" after clicking button while Firefox Nightly 109 does not do anything.

Changing status to "New". Thanks!

[Ryosuke Niwa]

Chrome behaves this way as well.

[Ahmad Saleem]

Created attachment 463591 [details]
Video Recording - Chrome Canary 110 & Safari 16.1 on "Tweaked" testcase

Just a video of what I am experiencing with "tweaked" testcase.