1782628 - `HTMLEditor::HandleInsertBRElement` may return invalid point as a suggest point to put caret

Status: RESOLVED FIXED

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

Description

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

I'm looking for the STR, but I found this bug at reading the code. I'm not sure why this mistake was not detected by static code analysis.

    return CreateElementResult(
        std::move(brElement),
        EditorDOMPoint(brElement, InterlinePosition::StartOfNextLine));

brElement is cleared at the first argument, but used at creating the second argument.

Comment 1

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

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

Comment 2

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

I don't see any fail caused by this with writing tests, so I think that we don't need to uplift the coming patch because the behavior is buggy in the case, anyway.

Comment 3

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

Attachment: Bug 1782628 - Make `HTMLEditor::HandleInsertBRElement` create caret position before moving its container r=m_kato!

The test oddly passes without the fix in HandleInsertBRElement. I guess that
post-processing in HTMLEditor::OnEndHandlingTopLevelEditSubActionInternal()
handles Selection, and anyway the insertion point of the following
insertText is wrong. It seems that we don't need to uplift this.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a674cb5f069f
Make `HTMLEditor::HandleInsertBRElement` create caret position before moving its container r=m_kato

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/a674cb5f069f