Impossible to put cursor before uneditable span inside contenteditable
Categories
(Core :: DOM: Selection, defect, P3)
Tracking
()
People
(Reporter: jonas, Unassigned)
References
Details
Attachments
(1 file)
|
231 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Steps to reproduce:
It's impossible to put the cursor in front of a <span contenteditable="false"> element inside a contenteditable element, neither with arrow keys, nor with the mouse. On Chrome this problem doesn't exist.
|
||
Comment 1•3 years ago
|
||
Yeah, I can reproduce. Masayuki, this seems like a bug?
Yeah, related to bug 1612076. Perhaps, I should solve this kind of issues after fixing current big work.
Thanks a lot for looking into this Masayuki. Highly appreciated. For some context, this affects all web editors building on top of contenteditable (i.e. everything using ProseMirror, CodeMirror, Tiptap and the like).
Did you have time to look into this in the meantime Masayuki? Unfortunately this bug results in poor user experience with Firefox on many online editors (e.g. everything based on prosemirror or Tiptap).
It's hard to say because there is no any official consideration of prioritizing contenteditable="false" related issues. However, the big work is now really close to the end, it was shipped in the Nightly channel and early beta builds. Therefore, I might start to work around this kind of issues.
Thanks for the assessment! I already saw that your big project landed in Nightly finally. Congratulations!
I investigated a little in my spare time. There are 2 points:
When caret is moved from another line to a line which begins/ends with a non-editable thing:
When we scan from a editable line edge to next line which begins or ends with a non-editable thing, first traversedFrame here is the non-editable leaf, e.g., if non-editable text, the non-editable text frame. It's considered as "not selectable". Therefore, we'd like to return the editable point immediately before or after the non-editable node in the line. However, I don't know how to compute it. Some ancestor frames may be non-editable. E.g., there are inline frames for non-editable <b>, etc. And the line itself may be non-editable. E.g., entire the paragraph has contenteditable=false.
When caret is moved from editable content and skip a non-editable thing which is start or end of the line:
When we can from a editable point next to start/end of a non-editable thing which is at start/end of the line, traversedFrame here is the non-editable leaf. I also don't how to compute the editable line edge here.
Emilio, do you have any ideas about computing the editable point from a non-editable frame?
FYI: This will be covered by the new test adding in bug 1612076.
|
||
Comment 9•2 years ago
•
|
||
So, I'm confused, not sure what the question is... (edit: disregard this, figured out while writing the reply :P)
My understanding is that this IsSelectable check would end up making us jump over the non-editable stuff. Doesn't the frame traversal not hit the editable region outside? I guess not, because we're only traversing leaves (see the eLeaf bit), and there's no leaf frame between the editable <p> and the non-editable <span>.
It seems that loop as a whole needs to be rethought a bit to handle this situation. Maybe not using a leaf-only traversal is enough, or maybe we need to do something custom to find the closest editable / selectable previous sibling.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)
My understanding is that this
IsSelectablecheck would end up making us jump over the non-editable stuff.
Yes.
Doesn't the frame traversal not hit the editable region outside? I guess not, because we're only traversing leaves (see the
eLeafbit), and there's no leaf frame between the editable<p>and the non-editable<span>.
Ah, yes, that's the root cause of this bug.
It seems that loop as a whole needs to be rethought a bit to handle this situation. Maybe not using a leaf-only traversal is enough, or maybe we need to do something custom to find the closest editable / selectable previous sibling.
Thanks, I didn't realize that the traversal class has other modes to walk the frame tree.
However, using the other modes for the loop wastes the runtime cost too much. On the other hand, looks like that the mode is checked only when walking the tree. So, the caller could override it temporarily. So, we could create a new method like Retraverse(nsIteratorType) and use it only when it reaches a non-editable leaf.
|
Reporter | |
Comment 11•1 year ago
|
||
@masayuki just a friendly poke, do you have news regarding this issue?
|
|
Reporter | |
Comment 12•7 months ago
|
||
Unfortunately this bug still exists and causes issues in all sorts of text editors that use contenteditable. Is there anybody working on it?
No. Currently, contenteditable=false handling does not have higher priority than the other editing features.
Description
•