NEW 41358
Selection offset does not update when DOMCharacterDataModified fires 
https://bugs.webkit.org/show_bug.cgi?id=41358
Summary Selection offset does not update when DOMCharacterDataModified fires
Nikita Vasilyev
Reported 2010-06-29 09:57:40 PDT
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
Attachments
Reduction (952 bytes, text/html)
2010-06-29 09:57 PDT, Nikita Vasilyev 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Ahmad Saleem
Comment 1 2022-06-02 21:47:42 PDT
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!
Note You need to log in before you can comment on or make changes to this bug.