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.

I'll investigate

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?

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

Backed out for causing mochitest failures in editor/libeditor/EditorEventListener.cpp

Backout link: https://hg.mozilla.org/integration/autoland/rev/3fc6f92c39b0078fb960659c2f95716cc0102968

Push with failures

Failure log -> Assertion failure: aEvent->GetCurrentTarget()->IsRootWindow(), at /builds/worker/checkouts/gecko/editor/libeditor/EditorEventListener.cpp:325

Backed out for causing reftest crashes

Backout link: https://hg.mozilla.org/integration/autoland/rev/2378eeed1ce08729195ead37e37b8fbcd903dd4d

Push with failures

Failure log ->

also these
wpt failures

wpt failures #2

build bustage

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

Backed out as requested by dev for causing regressions

Backout link

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/a32ab2262c46

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.

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

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.