1789344 - Selection after inserting paragraph at `abc<span>[def</span>]ghi` is wrong

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P2)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

STR

1. Load https://jsfiddle.net/d_toybox/bs9ym2cf/

Actual Result

Caret appears at end of the line

Expected Result

Caret should appear between "c" and "g".

This is reproducible even in ESR 91.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The regression range is:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7a3f514cf8490d271ee373a1d2999e4ea4dee2d7&tochange=b043233ec04f06768d59dcdfb9e928142280f3cc

Perhaps, regression of bug 1297414.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1297414

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1789344 - Make `SelectionState::DidMoveNode` track DOM points having pointed the moved content correctly r=m_kato!

When selection is abc<b>[def</b>]ghi, insertParagraph command will delete
the <b> element first, then, Selection becomes abc{}ghi. Then,
HTMLEditor::InsertParagraphSeparatorAsSubAction wraps all of the line in
the default paragraph, <div>, with
HTMLEditor::FormatBlockContainerWithTransaction (although this is incompatible
behavior with the other browsers). At this time, new <div> is inserted before
the first text node and then, move the text nodes into the new <div>.

However, RangeUpdater::DidMoveNode just slides the offsets if containers of
registered DOM points are the ex-parent of the moving nodes. Therefore, the
tracked selection range in HTMLEditor::FormatBlockContainerWithTransaction
become <div></div>abc{}def, then, <div>abcdef</div>{}, but the expected
behavior is of course, <div>abc{}def</div>, then, split the new <div>.

So the problem is, DidMoveNode assumes that DOM points won't point the moving
content node. If the node is pointed, it should keep pointing in the new
parent.

Note that the expectations of new tests are based on Chrome, therefore, the
new known failures are incompatible with Chrome.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/713c1697c555
Make `SelectionState::DidMoveNode` track DOM points having pointed the moved content correctly r=m_kato

Comment 5

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/35870 for changes under testing/web-platform/tests

Comment 6

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/713c1697c555

Comment 7

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot