Unable to focus in nested tiptap editor inside custom node view on Safari

[engram-design]

We use a custom node view to allow content to be added inside tiptap content in the form of "blocks". See the below for a demo:

You'll notice we mix node content (paragraphs) with our own blocks of different fields. This is used in Craft CMS plugin to allow CMS fields to be included. You'll also notice you can nest tiptap editors inside the custom nodes we provide, as illustrated above in "Columns" blocks.

What we're seeing is that on Safari (Mobile and Desktop) you're unable to focus on a nested tiptap editor. We've isolated this to a single setting of draggable: true for the custom node view. Removing this works as expected, allowing you to focus on the nested editor.

For a working example, open this in Safari: https://codesandbox.io/s/tiptap-issue-template-forked-7rsq8?file=/src/components/CustomNode.vue and try to focus on the "Nested text" paragraph node in the nested editor. All other browsers seem to be working correctly. Commenting out the draggable: true in the CustomNode.js file makes it work correctly in Safari.

All up to date with tiptap as well.

[philippkuehn]

Hey, I can reproduce your issue. I also found some weird behavior in Firefox. I posted the issue at the ProseMirror board. Let’s see: https://discuss.prosemirror.net/t/nested-draggable-editors-behave-differently-in-all-browsers/3807

But can I ask you why you decided to use nested editors and not just one editor? It’s pretty similar what Statamic is doing for its Bard field type:

[engram-design]

Thanks @philippkuehn, I should've checked if that was an issue with ProseMirror itself. It's indeed similar to Bard, but also gives users the option to have nested tiptap editors for all manner of needs. Say in the above screenshot you wanted to enable bold/italic for the "Caption" field, and have that as a rich text editor. Just gives people some more flexibility.

[philippkuehn]

Say in the above screenshot you wanted to enable bold/italic for the "Caption" field, and have that as a rich text editor. Just gives people some more flexibility.

I don’t see why this shouldn’t be possible with one single editor + node views.

[engram-design]

Maybe it's my lack of knowledge, but not clear on how to achieve that, sorry! Users also want to be able to nest blocks (the custom node) which is the reason for a nested tiptap editor as well.

[philippkuehn]

Something like this could be a start: https://codesandbox.io/s/nested-blocks-tkicz?file=/src/components/Tiptap.vue

[engram-design]

@philippkuehn Hmm, good point. I'll see if I can re-factor things as this might be better in the long-term.

[engram-design]

@philippkuehn Out of interest, one of the things that was holding me back on this approach was being able to have each block have an independent editor instance, so you can have different button/extensions enabled. While this'll work (as per your demo), it does show all instances of the "Bold" button as active, when you click on any button.

Here's a slightly tweaked version (as the second level nested node doesn't have an editor enabled, but a third-level does).

https://codesandbox.io/s/nested-blocks-forked-lgipb?file=/src/components/CustomNode.vue

I don't suppose there's any way to get around this - if the entire field is using a single editor?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mgtcampbell]

@engram-design did you ever end up solving this issue? I know it's going back a while!

I have a similar situation where I would like to:

• Allow one user to add custom nodes that represent form fields alongside other content (headings, paragraphs, lists etc)
• Save that content into a read only state
• Allow another user then to view the full content, but only add/edit content inside those custom nodes, and ideally using a "slimmed down" tiptap instance with less extensions included

Any advice would be greatly appreciated

[engram-design]

I don't believe I ever solved this one, but I think we might be able to use the stopEvent as there's a few other things where using draggable has caused us issues.

[mgtcampbell]

Thanks Josh - appreciate you coming back to me 👌