Created attachment 60031 [details] Reduction See reduction. The problem is, both range.startOffset and range.endOffset have previously selected offset, while range.startContainer and range.endContainer are pointing to the actual (ie new) nodes. It makes impossible (?) to get actual selection within DOMCharacterDataModified event. I've looked to the specs [1], [2] and didn't find any clarification what UA should actually do. But what they do now is not useful at all. I compared Firefox 3.6.6 with WebKit. Firefox behaves slightly less wrong: 1) When pressing delete or backspace key, range.startOffset and range.endOffset actually match to the current selection 2) getSelection().isCollapsed is always false, no matter what was selected before [1]: http://www.w3.org/TR/DOM-Level-3-Events/#event-type-DOMCharacterDataModified [2]: http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html
I am still able to reproduce this bug using attached "reduction" in Safari 15.5 on macOS 12.4. It matches with Firefox Nightly 103 incorrect behavior where "caret" does not follow "Selection" and "typing". Chrome Canary 104 seems to have fixed this issue. Thanks! It might have got fixed in Chrome's LayoutNg project since I was not able to find any relevant "FIXED" bug by using "range.startOffset" as search on Chrome's monorail. Thanks!