1750588 - Contenteditable content of web component cannot be removed when multiple paragraphs ending at the end of one are selected

Status: VERIFIED FIXED

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

Description

[Markus]

Attachment: webcomponent_firefox_issue.html

Steps to reproduce:

1. Open the attached HTML file in Firefox 96
2. In the bottom input field (a contenteditable web component), select everything except the "1" character (i.e. from 2 to 4, including)
3. Hit backspace, or delete, or CTRL+X, or type something

Problem only occurs if the web component is itself the contenteditable. If instead a contenteditable div is wrapped by a web component, then everything seems to work correctly.
I tried this on different machines and operating systems, including a fresh profile. Misbehaviour is reliably reproducible.

Actual results:

Nothing happens, the selected text remains in place.

Expected results:

The selected text should be removed through any of the actions from step 3.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Patrick (he/him)]

Able to reproduce issue in Firefox 96.0.1 and Nightly 98.0a1 (2022-01-19) on Windows

Comment 3

[Patrick (he/him)]

Regression - last good build 2021-08-20, first bad build 2021-08-21. From mozregression:

2022-01-20T17:02:01.752000: DEBUG : Found commit message:
Bug 1726064 - part 11: Make AutoBlockElementsJoiner::PrepareToDeleteNonCollapsedRanges() use HTMLEditUtils::GetInclusiveAncestorElement() r=m_kato

I have no idea how to test this without making unrealistic cases with legacy
mutation event listeners because now, Gecko ignores selection ranges which
crosses editing host boundaries when it tries to delete selection.

• https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/editor/libeditor/HTMLEditorDeleteHandler.cpp#1120
• https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/editor/libeditor/EditorUtils.cpp#137
• https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/editor/libeditor/EditorUtils.cpp#119-125

So, aRangesToDelete.FirstRangeRef() shouldn't be in different editing host.

Depends on D122948

Differential Revision: https://phabricator.services.mozilla.com/D123029

Comment 4

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

Thank you for reporting this bug and finding the regression point. I'll take a look tomorrow.

Comment 5

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

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

Comment 6

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

Attachment: Bug 1750588 - Make `AutoBlockElementsJoiner` handle deletion even when there is no ancestor block element of start or end range boundary r=m_kato!

HTMLEditor assumes that inline elements cannot have block elements. However,
it's not so if it's created by DOM APIs like Node.appendChild or making a
custom element an editing host.

Therefore, it's not unexpected case that only start or end of a range does not
have a block ancestor element. So this patch makes AutoBlockElementsJoiner
not stop handling the deletion in the case.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ac8115af1856
Make `AutoBlockElementsJoiner` handle deletion even when there is no ancestor block element of start or end range boundary r=m_kato

Comment 8

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

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

Comment 9

[Norisz Fay [:noriszfay]]

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

Comment 10

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

Upstream PR merged by moz-wptsync-bot

Comment 11

[Patrick (he/him)]

Issue no longer reproducible in Nightly 98.0a1 (2022-01-25)

Comment 12

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

-> v per comment 11 (thank you!)