Bug with custom node view, selecting and dragging

[engram-design]

I've come across an issue when using custom node views for a node. There's strange behaviour with being unable to select a node, unless you click on the drag cursor first, then it becomes selectable.

To illustrate, refer to this sandbox code https://codesandbox.io/s/tiptap-issue-template-forked-z5rf7?file=/src/components/CustomNode.vue

I've also take a video to illustrate the behaviour. Note that you can't click on any of the nodes' text to select the node. But as soon as you click the drag cursor (you don't even have to move it) you can now select the nodes by clicking anywhere in the block, as would be expected initial behaviour.

Screen.Capture.on.2021-02-10.at.22-56-59.mov

[engram-design]

Sorry for the delay in testing this, just bumped everything up to the latest beta versions and whilst this is working better, its removing focus on the elements inside each block.

To illustrate, I've updated my example sandbox - https://codesandbox.io/s/tiptap-issue-template-forked-z5rf7 - to include an input, which is what my (more detailed) custom node handles in a real-life scenario. I've added handling to the custom node to not simply clear the block when you start typing when a block node is selected - maybe that's part of the issue? This was working correctly before your change though.

In any case, when you try to type in the input, you're unable to as the focus on the block seems to be taking priority.

[philippkuehn]

Hey @engram-design,

there are some dependency issues at your codesandbox (some has changed in the last weeks for node views)

• please use @tiptap/starter-kit instead of @tiptap/vue-starter-kit (depecated)
• please use @tiptap/vue-2 (or @tiptap/vue-3 for vue 3 projects) instead of @tiptap/vue (depecated)

In addition, I think you misunderstood selected. It means that there is a NodeSelection — and not that the node has focus. So that a node can be selected and removed (with backspace) is intended behavior by ProseMirror. (btw: you can create a NodeSelection for any node with cmd+click). You can disable that by setting selectable: false but keep in mind that selectable is required for draggable.

At the moment all clicks at inputs will be ignored by ProseMirror:
https://github.com/ueberdosis/tiptap-next/blob/bdccc66d0f11e5b13290f99c2ed8c16c8bbb3a58/packages/core/src/NodeView.ts#L96-L101
That means if you click at a input within a node view, no NodeSelection will be created and selected will not change.

Does that make sense to you? If not: what would you expect?

[engram-design]

Thanks for the heads up on the dependancy stuff, I should've kept a closer eye on those updates. That actually solves this issue, so sorry about bringing this up again!

[engram-design]

Sorry to keep posting, and this is slightly another topic, but still relevant.

My use-case is being able to nest Tiptap editors - complex I know - which was working fine, but there's a slight hiccup with the focus logic in the latest beta's. I'm trying to hone in on exactly what's changed to be helpful.

But, you can see what's going on in https://codesandbox.io/s/tiptap-issue-template-forked-z5rf7?file where I'm nesting two Tiptap editors, one is inside a custom Vue component.

Try and click at the end of "Nested intro text" to add more text to this line and editor, and it'll shift the focus to the outer Tiptap editor.

vrVodl.mp4

The only way I can get it to select text is to select the text, which is probably tied to the drag logic.

To provide some extra context, what this means for my use-case, is that I can no longer detect the focused state on nested editors, which I use for all sorts of things, but namely to show a floating menu. Here's a video of my actual issue in context.

tLLG12.mp4

Here, I'm trying to click on an empty line in an editor, which of course works fine for the outer editor, but for the nested one, its bubbling up to the outer editor.

In earlier alpha versions, this wasn't an issue and was working correctly. Something just seems to be taking focus.

[philippkuehn]

Hey, I've added a patch to improve that behavior.

[philippkuehn]

But I just see that drag & drop is not yet running smoothly with nested editors. I’ll have to look at that again.

[engram-design]

@philippbosch Ah, perfect! Didn't think to suggest target.isContentEditable but that makes total sense, and works well.