Closed Bug 1685300 Opened 4 years ago Closed 2 years ago

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

Categories

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

Firefox 84
defect

Tracking

()

RESOLVED DUPLICATE of bug 1496769

People

(Reporter: marijnh, Assigned: masayuki)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

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.

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

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

Kagami, can you look into this?

Flags: needinfo?(krosylight)

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

Just to clear NI:

Assignee: nobody → krosylight
Flags: needinfo?(krosylight)
Severity: -- → S3
Priority: -- → P3

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

Assignee: krosylight → nobody
Flags: needinfo?(masayuki)

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?

Flags: needinfo?(masayuki) → needinfo?(marijnh)
Alias: stop-editor-using-focus/blur-events
OS: Unspecified → All
Hardware: Unspecified → All

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.

(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.

Assignee: nobody → masayuki
Status: NEW → ASSIGNED

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.

Flags: needinfo?(marijnh) → needinfo?(htsai)
Flags: needinfo?(htsai)
Alias: stop-editor-using-focus/blur-events
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: