Editor in dialog overlapping another breaks SideMenu and drag-and-drop

[sauerben]

What’s broken?

We have a setup with an editor and a button next to it that opens another editor instance in a dialog above it. In areas where the two editors directly overlap, the SideMenu does not appear in the topmost editor. Drag and drop is also not possible in these overlapping areas.

blocknote-overlapping.mp4

The root cause is likely in findClosestEditorElement (in SideMenu.ts) because it does not consider the z-axis stacking order when determining the editor element.

What did you expect to happen?

Option 1
Ensure Sidebar and drag-and-drop interactions only consider the topmost editor.

Option 2
Add an option to exclude specific editors (for example editors behind a dialog) from the hover and drag detection logic.

Steps to reproduce

Having an editor in a dialog above another editor

Demo:
https://react-shadcn-blockno-nf9x.bolt.host

BlockNote version

No response

Environment

No response

Additional context

No response

Contribution

• I'd be interested in contributing a fix for this issue

Sponsor

• I'm a sponsor and would appreciate if you could look into this sooner than later 💖

[YousefED]

Thanks for reporting! We'll look into this, but as it's a pretty specific case it might be a while before we get to this.

Curious to hear what you're building btw!

[thomastrapp]

I have tripped over the same problem.

I have a page where the Blocknote editor is used twice:

• a read-only display of some content with <BlockNoteView editable={false} ...>
• a dialog, where another editor is used

If the editor in the dialog is displayed on top of the read-only editor, then findClosestEditorElement seems to prefer to find the read-only editor in the background. And then the side menus are broken, like is shown in the video.

The following change excludes non-editable editors in findClosestEditorElement, and fixes the issue for me:

--- SideMenu.ts
+++ SideMenu.ts-patched
@@ -325,7 +325,7 @@ private findClosestEditorElement = (coor
     clientY: number;
   }) => {
     // Get all editor elements in the document
-    const editors = Array.from(this.pmView.root.querySelectorAll(".bn-editor"));
+    const editors = Array.from(this.pmView.root.querySelectorAll('.bn-editor:not([contenteditable="false"])'));
 
     if (editors.length === 0) {
       return null;

I am unsure if this is an acceptable solution in general. I wonder if there is a workaround.

[nperez0111]

Hi @thomastrapp this isn't that great of a solution, it just happens that you have something to distinguish between the editable and the non-editable instance. Whereas the reported issue has two editor instances.

There will probably need to be some sort of ranking algorithm or expose some configuration to make sure that this picks the right instance of the editor. I have a suspicion that this is likely just returning results in dom order, and modals often are implemented as being at the end of the body on a page

[thomastrapp]

Thank you for working on Blocknote @nperez0111 ! I really like it.

this isn't that great of a solution, it just happens that you have something to distinguish between the editable and the non-editable instance. Whereas the reported issue has two editor instances.

I agree.
Although maybe a case could be made that the side menu cannot interact with editors that are read-only, and therefore they should be excluded.

I have a suspicion that this is likely just returning results in dom order

This is only the case when the cursor is inside of two or more .bn-block-groups. Then the first editor in document order is returned.
But, if the cursor is outside of a .bn-block-group, for example when trying to hover the side menu, which is outside and to the left of its .bn-block-group, then the distance calculations decide which editor "wins".

For example, if the mouse hovers over the side menu of the first editor in document order, the distance there is greater than zero.
If behind the first editor, is a second editor, and it just so happens that the current mouse position is inside one of its .bn-block-groups, then that distance is zero. Therefore this second editor will always be considered "closer", without regard to the document order.

If findClosestEditorElement takes into account the width of the side menu, then this problem goes away and document order does take precedence when editors overlap. Which would be an acceptable solution, from a user perspective, I think.