Fix dropcursor not updating the position on ongoing drag-event #24

Closed
bdbch wants to merge 2 commits from bdbch:fix/dropcursor-invalid-position-on-update into main
First-time contributor

This PR should fix issue prosemirror/prosemirror#1573. I tried to avoid using plugin states to store the prosemirror positions and map it across transactions and instead rely on recomputing the position of the dropcursor the same way we do on dragover.

This PR should fix issue https://code.haverbeke.berlin/prosemirror/prosemirror/issues/1573. I tried to avoid using plugin states to store the prosemirror positions and map it across transactions and instead rely on recomputing the position of the dropcursor the same way we do on `dragover`.
Owner

Thanks. What is the reason for the lines that clear lastEvent? I'd say that there's no harm in just keeping that around (which would also allow us to drop the this.cursorPos > editorView.state.doc.content.size branch). If you're worried about leaking event.target, we could also just store an {x, y} pair.

Thanks. What is the reason for the lines that clear `lastEvent`? I'd say that there's no harm in just keeping that around (which would also allow us to drop the `this.cursorPos > editorView.state.doc.content.size` branch). If you're worried about leaking `event.target`, we could also just store an `{x, y}` pair.
Author
First-time contributor

What is the reason for the lines that clear lastEvent?

I wanted to make sure that we don't somehow end up with a stale lastEvent state and to clear the event when it was handled/canceled but I think you're right and it wouldn't really do any harm, since we always get a fresh one on dragover.

If you're worried about leaking event.target, we could also just store an {x, y} pair.

Yeah basically what I said above but I think you're rightfully questioning if we can just keep it. I think we're fine with just going with keeping the event.

> What is the reason for the lines that clear `lastEvent`? I wanted to make sure that we don't somehow end up with a stale `lastEvent` state and to clear the event when it was handled/canceled but I think you're right and it wouldn't really do any harm, since we always get a fresh one on dragover. > If you're worried about leaking `event.target`, we could also just store an {x, y} pair. Yeah basically what I said above but I think you're rightfully questioning if we can just keep it. I think we're fine with just going with keeping the event.
Author
First-time contributor

Hey @marijn I updated the PR. I removed the max content size overflow branch & also kept the lastEvent now across different drag events and everything worked fine on my end. Let me know if you think something else is off or you'd like some adjustments.

Hey @marijn I updated the PR. I removed the max content size overflow branch & also kept the `lastEvent` now across different drag events and everything worked fine on my end. Let me know if you think something else is off or you'd like some adjustments.
Owner

Thanks, looks great now. Merged as 8ca91f1

Thanks, looks great now. Merged as 8ca91f1
marijn closed this pull request 2026-06-17 08:29:51 +02:00
bdbch deleted branch fix/dropcursor-invalid-position-on-update 2026-06-18 11:09:43 +02:00

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
prosemirror/prosemirror-dropcursor!24
No description provided.