-
Notifications
You must be signed in to change notification settings - Fork 3.3k
Open
Labels
Description
Hi there 👋
I was investigating a gnarly issue in an app that unfortunately is closed source and quite difficult to create a reproduction sandbox from. In any case, I thought I would write up what I found about how DOMEditor.toSlatePoint can end up producing a wrong point in a nested editor scenario:
- If the editor is read-only and therefore is marked as
contenteditable="false"thennonEditableNodecould end up being the editor itself:slate/packages/slate-dom/src/plugin/dom-editor.ts
Lines 722 to 725 in a8fc9a4
const nonEditableNode = potentialNonEditableNode && editorEl.contains(potentialNonEditableNode) ? potentialNonEditableNode : null - And if there's no
leafNodebecause the event origins from a non-leaf then we end up in the} else if (nonEditableNode) {clause:let leafNode = parentNode.closest('[data-slate-leaf]') - Inside this clause, if the editor is nested inside another editor then
nonEditableNode.closest('[data-slate-node="element"]')can potentially find a node inside the parent editor:slate/packages/slate-dom/src/plugin/dom-editor.ts
Lines 811 to 813 in a8fc9a4
const elementNode = nonEditableNode.closest( '[data-slate-node="element"]' ) - Further down
DOMEditor.toSlatePoint,DOMEditor.toSlateNodeis called:const slateNode = DOMEditor.toSlateNode(editor, textNode!) - But since this method uses the global
ELEMENT_TO_NODEWeakMap, it will probably return a Slate node even though it's from another editor:const node = domEl ? ELEMENT_TO_NODE.get(domEl as HTMLElement) : null
I suppose this is a bug? Could it be mitigated it by adding a check to see if nonEditableNode is the editor itself and then return the start or end of the editor depending on the searchDirection?