a contenteditable element inside an element with tabindex(which is inside a Shadow DOM), fails to display the caret when the focus is changed inbetween shadow elements
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox64 | --- | affected |
People
(Reporter: zjz, Unassigned)
References
(Blocks 4 open bugs)
Details
Attachments
(2 files)
Please see the uploaded test.html
Reporter | ||
Comment 1•6 years ago
|
||
Since the bug is relevant to both the contenteditable feature and the shadow DOM, so I am CC'ing both of you.
Comment 2•6 years ago
|
||
Editor initializes caret/selection at receiving focus event. So, the editable element does not receive focus event or the focus event listener of editor is not shadow DOM aware.
Updated•6 years ago
|
Comment 3•6 years ago
|
||
Also faced this issue, reproduced here: https://jsfiddle.net/webpadawan/g6vku9L3/
Comment 4•6 years ago
|
||
In the "move-focus to the inner element inside the shadow DOM" case, in all browsers, there's no extra focus event dispatched. So editor should probably use a different method other than regular event listeners in order to handle this.
Comment 5•6 years ago
|
||
Olli, do we have an easy way to somehow end up dispatching the focus event here at least for the system event handlers? Or should we just move that focus event handler to get notified via nsFocusManager instead or such?
Updated•6 years ago
|
Comment 6•6 years ago
|
||
If listener is added to chrome event handler, it should get the event. And listener could then use composedTarget
Assignee | ||
Updated•5 years ago
|
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.
Updated•2 years ago
|
Comment 11•2 years ago
|
||
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.
Comment 12•2 years ago
|
||
FYI: Initializing Selection
in the focused editing host may run chrome script, it makes the things complicated and harder to fix this.
Comment 13•2 years ago
|
||
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.
Comment 14•10 months ago
|
||
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).
Updated•10 months ago
|
Description
•