Closed Bug 1817723 Opened 1 year ago Closed 1 year ago

Having multiple editable elements in a shadow root breaks selection

Categories

(Core :: DOM: Selection, defect)

Product:
Core
Component:
DOM: Selection
Version:
Firefox 109
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
117 Branch
Tracking Flags:
Tracking Status
firefox117 --- verified
firefox118 --- verified

People

(Reporter: marijnh, Assigned: sefeng)

References

Details

Attachments

(3 files)

test.html
(deleted), text/html
Details
Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki
(deleted), text/x-phabricator-request
Details
Bug 1817723 - Make WindowFromListener to return the inner window for KeyPress event if current event target is nsWindowRoot r=masayuki
(deleted), text/x-phabricator-request
Details
Attached file test.html (deleted) —

Multiple contentEditable elements sharing a shadow root seem to interact in some way that causes issues. If you first focus one and then another, the cursor is not drawn in the second element. If the selection happens via a script, a second problem occurs in which the selection is not updated on typing, causing characters to appear in the wrong order because the cursor stays in front of the typed content.

Attached HTML page contains a minimal reproduction of the issue.

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

I'll investigate

Severity: -- → S3
Flags: needinfo?(sefeng)

The cursor is not drawn because the focus switching was done within the same shadow tree, and the HTMLDocument doesn't receive the focus event because the event chain building stops at https://searchfox.org/mozilla-central/rev/55d5c4b9dffe5e59eb6b019c1a930ec9ada47e10/dom/base/FragmentOrElement.cpp#973. We need the HTMLDocument to receive the focus event because EditorEventListener is registered there.

Olli, I think what we have seem to be matching the spec, do you think we should special case this?

Flags: needinfo?(sefeng) → needinfo?(smaug)

Which spec? EditorEventListener is a Gecko internal thingie.
Should the EditorEventListener be added to the parent of Window and then event propagated there?

Flags: needinfo?(smaug)
Assignee: nobody → sefeng
Attachment #9334174 - Attachment description: WIP: Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between shadow dom elements. → Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki
Status: NEW → ASSIGNED
Attachment #9334174 - Attachment description: Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki → WIP: Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki
Attachment #9334174 - Attachment description: WIP: Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki → Bug 1817723 - Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki
Pushed by sefeng@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e8b6a5dbf398
Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki
Pushed by sefeng@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6a96bb1f430f
Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki
Pushed by sefeng@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f9f8e7cfe057
Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki

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

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox116: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 116 Branch
Regressions: 1839660

Backed out as requested by dev for causing regressions

Backout link

Status: RESOLVED → REOPENED
status-firefox116: fixed → ---
Resolution: FIXED → ---
Target Milestone: 116 Branch → ---

Currently, the returned inner window will be nullptr if mTarget is a
nsWindowRoot and this causes nsPIDOMWindow::SetEvent can not be called, hence
window.event could be null in edge cases when scripts try to access it.
This can prevent React from working properly because React relies on
window.event to determine its internal event queue.

This only matters to KeyPress event because the only edge case I see
so far is related to how contenteditable elements handles KeyPress event.

Pushed by sefeng@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/82ec106ef2c5
Allow HTMLEditor can receive events when the focus is switched between elements in the same shadow tree. r=masayuki
https://hg.mozilla.org/integration/autoland/rev/b33104f8bcd8
Make WindowFromListener to return the inner window for KeyPress event if current event target is nsWindowRoot r=masayuki
https://hg.mozilla.org/integration/autoland/rev/b909a9f6f1ea
apply code formatting via Lando

https://hg.mozilla.org/mozilla-central/rev/82ec106ef2c5
https://hg.mozilla.org/mozilla-central/rev/b33104f8bcd8
https://hg.mozilla.org/mozilla-central/rev/b909a9f6f1ea

Status: REOPENED → RESOLVED
Closed: 1 year ago → 1 year ago
status-firefox117: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 117 Branch
Flags: needinfo?(sefeng)
Flags: qe-verify+

Reproducible on a 2023-07-05 Nightly build on macOS 12 using the testcase from Comment 0.
Verified as fixed on Firefox 117.0b2(build ID: 20230801180159) and Nightly 118.0a1(build ID: 20230802220030) on macOS 12, Windows 10, Ubuntu 22.

Status: RESOLVED → VERIFIED
status-firefox117: fixed → verified
status-firefox118: --- → verified
Flags: qe-verify+
Regressions: 1847363
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: