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.

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.

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

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

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

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

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.

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

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

-> v per comment 11 (thank you!)