Make `nsRange::CharacterDataChanged` stop droing wrong handling at split text
Categories
(Core :: DOM: Selection, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr140 | --- | unaffected |
| firefox-esr153 | --- | unaffected |
| firefox156 | --- | unaffected |
| firefox157 | --- | unaffected |
| firefox158 | --- | fixed |
People
(Reporter: masayuki, Assigned: masayuki)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
AI review pointed an extant bug of nsRange::CharacterDataChanged:
https://phabricator.services.mozilla.com/D323941#inline-1733034
The comment on line 630 says "register the range to the new common ancestor", but when only the end boundary moves to the new sibling (start stays on the original node), the registered node is not the actual common ancestor — it's just the new end container. The true common ancestor (the parent of both sibling nodes) is computed later by DoSetRange → UpdateCommonAncestorIfNecessary.
Perhaps, nsRange::CharacterDataChanged does not need to do it by itself...
| Assignee | ||
Updated•13 days ago
|
| Assignee | ||
Comment 1•12 days ago
|
||
Oh, when aContent is split, the new node has not been inserted to the DOM yet. So, nsRange needs to do that.
| Assignee | ||
Comment 2•11 days ago
|
||
If the range starts from the old Text and ends in new Text, the
closest common inclusive ancestor is the parent element, but current
code always treats the new Text as the closest common inclusive
ancestor.
| Assignee | ||
Comment 3•8 days ago
|
||
This is caused by a regression of bug 2069772. So, we have to fix this soon.
Comment 4•8 days ago
|
||
Set release status flags based on info from the regressing bug 2069772
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/62842 for changes under testing/web-platform/tests
Comment 7•6 days ago
|
||
| bugherder | ||
Upstream PR merged by moz-wptsync-bot
Description
•