This got me interested in how Prosemirror implements dragging of nodes that are editable since this is similar to that in a way. PM adds a draggable attribute on demand to such nodes (compare that to the example in glitch with a permanent draggable attribute), when it deems the user might be interested in drag. This makes me feel that a draggable attribute messes with an editable element and to solve the problem we might need to do something similar to what pm-view has done src code.
Sorry to reference Tiptap issues here, but I believe they might be ProseMirror issues, all related to dragging. In both bug cases, if we disable dragging on our custom node views, the issue is resolved. Please also feel free to direct me to this being a Tiptap issue, and not a ProseMirror one if you feel that’s the cause.
I’d argue they are browser issues—there’s no consensus on how draggable+editable text should work, and browsers do different things (even Chrome’s behavior isn’t ideal I think). It’s usually better to use drag handles separate from the editable text.
Yep, certainly seems like (wonderful) browser bugs. In our case, the drag handles are separate to the editable text, the OP video probably doesn’t show that very well.
Here’s some videos showing ProseMirror (via Tiptap) with custom node views that are draggable, but contain other elements that are clickable/selectable (a <textarea> element). You’ll note that we have a separate drag handle to control how to drag “blocks” of content. But in Firefox, as soon as we enable the custom node to be draggable it prevents any clicking on the inner <textarea>. Something tells me that it’s a browser quirk about the mouse-click event, potentially when listening for draggability?
Thanks for the clarification @philippkuehn do you think this would be an issue with Tiptap draggable handling? Sorry for my lack of understanding, but from looking at your link, that seems to be where the logic for handling dragging takes place (replacing rather than extending ProseMirror)?
I’m wondering if we’re able to disable draggable on the entire node view and only have it enabled for the drag handle - which is actually what we want anyway. But I think that’s more of a Tiptap thing.
Feel free to mark as closed, or maybe something to configure with Tiptap @philippkuehn .
I’ve kept the custom view using draggable: true as without it, we’d lose dragging functionality. Instead, after initialization, I’m removing the draggable="true" attribute from the DOM element. This doesn’t seem to affect draggability, but does fix Firefox’s inability to select text.