Closed Bug 1880710 Opened 1 year ago Closed 1 year ago

Text can not be deleted from a contenteditable element under a ShadowRoot in some cases

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Version:
Firefox 122
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
125 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- wontfix
firefox123 --- wontfix
firefox124 --- wontfix
firefox125 --- verified
firefox126 --- verified

People

(Reporter: james, Assigned: masayuki)

References

(Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(2 files)

firefox_shadow_contenteditable_text_deletion.html
950 bytes, text/html
Details
Bug 1880710 - Make `HTMLEditor::IsEmpty` check whether the editing host is empty r=m_kato!
48 bytes, text/x-phabricator-request
Details | Review

Steps to reproduce:

Follow this link in Firefox: https://james.diacono.com.au/files/firefox_shadow_contenteditable_text_deletion.html

Attempt to delete some text from first line, either by pressing Backspace, Delete, or cutting a selection.

Actual results:

The text is not deleted.

Expected results:

The text should have disappeared.

Text can still be deleted from the <textarea> element immediately below, and it can be deleted if the contenteditable element is lifted out of its ShadowRoot.

This is where things get really weird. The issue is also resolved if you insert a line break in the HTML source anywhere after the starting <body> tag, for example:

<body>\n</body></html>
<body></body>\n</html>
<body></body></html>\n

My user agent string is "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0".

Component: Untriaged → DOM: Editor
Product: Firefox → Core

I can reproduce the issue on Nightly124.0a1 Windows10.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9daae850d8829872fb915161ef065c584aacaff5&tochange=2ead36ea58f872f05750bed5e2a98631ae7863f5

Status: UNCONFIRMED → NEW
status-firefox124: --- → affected
Ever confirmed: true
Keywords: nightly-community, regression
OS: Unspecified → All
Regressed by: 1716728
Hardware: Unspecified → Desktop

:saschanaz, since you are the author of the regressor, bug 1716728, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(krosylight)

I'll take a look.

Assignee: nobody → masayuki
Severity: -- → S3
Status: NEW → ASSIGNED
Flags: needinfo?(krosylight)

A very similar bug is also trigged if the contenteditable element is not a <div>. If it is a <span> or <my-element>, for example, text can not be deleted except by pressing Backspace with a collapsed selection. Pressing the Delete key, or attempts to delete a selection using the Backspace or cutting, are futile. Should I open a new bug for this issue?

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

status-firefox125: --- → affected

It checks whether the document body itself is empty or not. However, if there
is only a shadow DOM hosts, it considers the content is empty. Therefore,
HTMLEditor::HandleDeleteSelection does nothing.

I think that it should check whether current editing host is empty or not.
That does not work without selection ranges, but I think it's fine in most
cases.

Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/de5749c78759 Make `HTMLEditor::IsEmpty` check whether the editing host is empty r=m_kato
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44723 for changes under testing/web-platform/tests

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

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox125: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 125 Branch
Upstream PR merged by moz-wptsync-bot

The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox124 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(masayuki)

This is not a new regression and the patch changes a traditional Chrome only API behavior. Therefore, we should not uplift it.

status-firefox124: affected → wontfix
status-firefox-esr115: affected → wontfix
Flags: needinfo?(masayuki)
QA Whiteboard: [qa-125b-p2]

Reproducible on a 2024-02-16 Nightly build on Windows 10.
Verified as fixed on Firefox Nightly 126.0a1 and Firefox 125.0 on macOS 12, Windows 10, Ubuntu 22.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-125b-p2]
status-firefox125: fixed → verified
status-firefox126: --- → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: