If listener is added to chrome event handler, it should get the event. And listener could then use composedTarget

I' more than willing to contribute and work on this. Can anyone point me in the direction where I can start? Thank you!

I've been battling with this bug this week. I ended up removing tabindex from my custom element in Firefox, which is obviously not great for a11y. On that note, even with the tabindex attribute removed, the delete key seems to be completely broken.

I've refactored around the focus/blur event handling of editor in bug 1770874 to make nsFocusManager notify HTMLEditor of focus change. However, it causes different issues, for example, in the case of when <input> or <textarea> has focus in a <div contenteditable>, delayed focus/blur events causing some failures of existing automated tests, etc. So, it's hard to say where you should change, then, you can fix this simply. I still don't have a concrete idea to fix this bug.

FYI: Initializing Selection in the focused editing host may run chrome script, it makes the things complicated and harder to fix this.

One possible simpler approach is, to make both TextEditor and HTMLEditor handle focus and blur without events, then, to make nsFocusManager directly notify them immediately after dispatching focus/blur events. Although this approach cannot fix the edge cases, e.g., focus/blur events are delayed, but JS tries to use the editor feature.

This bug 1496769 was resolved in Firefox's latest release. It seems like blinking caret disappearing in content editable element when focus changes under shadow dom got resolved in the latest release of Firefox browser (v117 - https://www.mozilla.org/en-US/firefox/117.0/releasenotes/).

You can verify the behavior using this test link https://bug1496769.bmoattachments.org/attachment.cgi?id=9014846,

• Working as expected in v117 of Firefox browser
• Having this issue in previous versions (v116 and before).