The following behavior occurs in the Embedded code editor example on the prosemirror website:
- Place cursor inside code editor
- Click somewhere inside the prosemirror content area but outside the code editor
- Observe the cursor is moved to the beginning of the code in the code editor
- Repeat step 2
- Observe the cursor appears in the place you clicked (as usual)
I would like to eliminate steps 3 & 4. Step 3 may be caused by the focus event handler in SelectionReader kicking off a chain of logic that eventually updates the selection based on the current state of the dom. Are there any suggested solutions for this?
I’m only seeing this in Chrome, and the source of the problem appears to be that Chrome briefly puts the selection at the start CodeMirror’s textarea-hiding wrapper node (which isn’t even editable, and away from the click, so that’s pretty weird behavior) before it moves it to the click target. ProseMirror will see that selection and convert it to a regular selection at the start of the code editor, updating the DOM selection before Chrome’s continues to move the selection to the clicked position.
The reason why it doesn’t happen on the second click is that there, the DOM selection already agrees to what ProseMirror thinks the selection is, so it doesn’t touch the DOM selection and thus doesn’t prevent the second selection jump to the mouse position.
I’m not sure what causes this browser behavior. I’m seeing similar bogus selections when I try to replicate the behavior in a simple DOM structure, but there the selectionchange event fires as soon as the textarea is focused, not when focus is moved away from it.