Caret in contentEditable content becomes invisible when next to uneditable element
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox123 | --- | fixed |
People
(Reporter: marijnh, Assigned: masayuki)
References
(Blocks 1 open bug)
Details
(Whiteboard: [h2review-noted], [wptsync upstream])
Attachments
(2 files)
Depending on the surrounding DOM structure and the way the cursor was moved somewhere, the caret is sometimes invisible when directly next to an uneditable inline element in an editable container.
In the attached HTML file, this can be reproduced by clicking anywhere in the first paragraph ("Normal"), and then pressing the down arrow key. There is no visible cursor, though the editable element still has focus and the DOM selection has a reasonable value (in the second paragraph at position 1).
Typing something at that point works and makes the cursor visible again. Backspacing out the typed text results in the exact same DOM selection (as visible from JavaScript), but this time the cursor is visible.
Possibly related to 1175495, though the circumstances that trigger this are different.
|
Assignee | |
Comment 1•6 years ago
|
||
Hmm, caret is moving the uneditable node and this makes users confused (although contenteditable="false" must not be used widely).
|
Reporter | |
Comment 2•6 years ago
|
||
contenteditable="false"must not be used widely
Modern editors often want to display rich content (mentions, markers, completions, and similar) inside editable content. If you don't set that to uneditable, you have to deal with the possibility of the user accidentally typing into your widgets, so there's a good reason to use uneditable elements inside editable content.
Some more details: The original file, where the uneditable element is in an otherwise empty paragraph, allows you to reproduce this with direct user arrow motion. If there's content around it, as in the demo below, the issue doesn't seem to come up with keyboard cursor motion, but does occur reliably when setting the cursor after the uneditable element with a script.
<div contenteditable=true>one<span contenteditable=false>X</span>two</div>
<script>getSelection().collapse(document.querySelector("div"), 2)</script>
Since CodeMirror makes quite heavy use of such widgets in the content, and version 6 builds on contenteditable for accessibility reasons, this is really quite a problem for us.
|
||
Updated•6 years ago
|
|
||
Updated•6 years ago
|
|
||
Comment 3•6 years ago
|
||
I just tried to reproduce this error in Mozilla Firefox 80.0a1 2020-07-23. The cursor does move down to the second paragraph but required two hits of the down-arrow and the text-cursor shows at the end of "UNEDITABLE". I wonder if the problem is that it requires two hits rather than a single hit.
|
|
Reporter | |
Comment 4•6 years ago
|
||
I'm still seeing the exact behavior described in the original issue in both 79 and 81 nightly (on Linux). After putting the cursor on the first line and pressing the down arrow, there is no visible cursor.
|
||
Updated•4 years ago
|
I can confirm that this bug still exists on Firefox 106.0 (Linux). Any chance to get it fixed?
|
|
Assignee | |
Updated•3 years ago
|
This issue still persists, but it is not present in Edge/Chrome/Safari.
|
|
Assignee | |
Comment 7•2 years ago
|
||
Oh, this is a simple bug.
|
|
Assignee | |
Comment 8•2 years ago
|
||
When pressing ArrowLeft key at:
<p>abc</p><p><span contenteditable=false>def</span>{}<br></p>
, caret is moved into the non-editable text because
nsCaret::GetCaretFrameForNodeOffset looks for a preceding text node from
the BRFrame. This is required if the preceding text node ends with a
collapsible white-space but followed by a <br> because the text frame
should not contain the white-space rect and BRFrame frame should be next
to it, i.e., the white-space looks like a overflown content.
So, for rendering a caret, the method needs to return non-editable text frame
even in the case, but for considering new caret position in the DOM tree, it
should not return non-editable text frame.
Therefore, this patch adds a param to nsCaret::GetCaretFrameForNodeOffset()
which forcibly return editable content frame or not and makes
Selection::GetPrimaryOrCaretFrameForNodeOffset call it with the new option
because its callers are the handler of caret navigation.
|
||
Comment 11•2 years ago
|
||
| bugherder | ||
Description
•