1685300 - contentEditable element in a shadow root fails to show cursor when moving focus from another editable element

Status: RESOLVED DUPLICATE of bug 1496769

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

Description

[Marijn Haverbeke]

Attachment: Example of the problem occurring

When two contentEditable elements exist inside a shadow root, focusing one and then using the mouse to move focus to the other one, you can type in the newly focused element, but no cursor is visible.

Possibly related, moving from one editable element to another with the keyboard (tab) doesn't seem to work the way it works outside of a shadow root either—I can see the focus ring appear on the newly selected element, but typing (again without cursor) still happens in the one that was initially selected.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Anne (:annevk)]

Kagami, can you look into this?

Comment 3

[Kagami [:saschanaz] (they/them)]

I see a different behavior on Windows: the typing doesn't work at all. I will investigate.

Comment 4

[Kagami [:saschanaz] (they/them)]

Just to clear NI:

Comment 5

[Kagami [:saschanaz] (they/them)]

Unassigning myself from inactive bugs. Masayuki, could you take a look? Thanks!

Comment 6

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

This is caused by editor and focus manager have not supported shadow DOM tree yet.

When focused element is not in the shadow DOM, focus event is fired on the document with original target is the shadow host. Then, initializing selection which is computed from focus node of Selection works, however, if focus is move in a shadow DOM, editor won't receive focus event because focus node has not occurred from point of view of document.

So we need to make nsFocusManager notify HTMLEditor of focus change directly and editor should stop using focus and blur event listeners.

Marijn Haverbeke: How much important this bug for you? Did you find this bug with experimenting something technically? Or did you find this with trying to create something which you want?

Comment 7

[Niklas Keller]

Masayuki: I'm not Martin, but I've found this bug while investigating an internal product bug at my company, and found this to be the root cause.

Comment 8

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

(In reply to Niklas Keller from comment #7)

Masayuki: I'm not Martin, but I've found this bug while investigating an internal product bug at my company, and found this to be the root cause.

Thanks. It does not make this bug urgent, but it means that this prevents a useful use case of contenteditable for some developers. And I check the source code briefly, it's hard to fix this with the ideal approach, i.e., making editor stop using focus and blur events. However, this could be fixable with lighter approach.

I try to fix this while waiting the pending reviews.

Comment 9

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:hsinyi, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.