fix: Cut/copy handling in non-editable blocks and empty selections

[matthewlipski]

This PR does 2 things:

When the selection is empty, we no longer use our own cut/copy handling and instead let the browser handle the event (so nothing happens). Currently an error is thrown as we attempt to create clipboard data from an empty selection.

When the selection is within a descendant of a "contenteditable"="false" element, we no longer use our own cut/copy handling and instead let the browser handle the event. This means the user is selecting some content in a non-editable block. Currently the editor selection is copied instead as this scenario still triggers PM event handlers.

TODO: Unit tests?

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
blocknote	✅ Ready (Inspect)	Visit Preview	Feb 11, 2025 11:53pm
blocknote-website	✅ Ready (Inspect)	Visit Preview	Feb 11, 2025 11:53pm

[YousefED]

Nice. What was the reason for working on this? Curious how / where you ran into it!

Code-wise, some questions / feedback:

• what if you're within a contenteditable="true" nested in a contenteditable="false"?
• you might be able to use closest() instead of looping upo the tree

[nperez0111]

lgtm

[matthewlipski]

Nice. What was the reason for working on this? Curious how / where you ran into it!

Code-wise, some questions / feedback:

• what if you're within a contenteditable="true" nested in a contenteditable="false"?
• you might be able to use closest() instead of looping upo the tree

Good point r.e. the contenteditable="true", I think it would make sense to return false if we hit an editable element before we hit a non-editable one, but I'll do some manual testing with that first.

[matthewlipski]

Ok looks like putting your contentDOM element within a "contenteditable"="false" element is not really supported by ProseMirror anyway (it gets very confused regarding positions). Alternatively if you had say, just a text box within a non-editable block, that text is not part of the editor state and so the browser should handle cut/copy events there.

Long story short looks like the current behaviour is fine

[matthewlipski]

Nice. What was the reason for working on this? Curious how / where you ran into it!

Code-wise, some questions / feedback:

• what if you're within a contenteditable="true" nested in a contenteditable="false"?
• you might be able to use closest() instead of looping upo the tree

Also r.e. using closest(), here it doesn't make much sense to do since the event target may just be a text Node, and closest() is only available on Elements. So we would have to traverse the parents until an Element is found to call closest(), and at that point we may as well just continue traversing the parents instead.