You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Configurable drag'n'drop preview container in SideMenuPlugin #1685
Is your feature request related to a problem? Please describe.
My Custom Blocks rely on CSS variables from their parent nodes. That means that when I use the drag handle to drag and drop them I lose styling properties and drag and drop preview doesn't look good.
Describe the solution you'd like
A configurable option to specify the selector for the parent of the drag and drop preview. The SideMenuController seems like a good place for it. I could take a stab at implementing it.
Describe alternatives you've considered
An alternative is for me to rewrite my app in a way that does not rely on CSS variables set up the DOM tree. I'd rather not do that.
Additional context
As you can see in the video, button's text color and background are part of the theme specified on the Editor's parent. The dragged button loses it's styles.
Screen.Recording.2025-05-14.at.12.33.38.mov
Bonus
[ ] I'm a sponsor and would appreciate if you could look into this sooner than later 💖
@nperez0111 I'm starting to think using a library like html2canvas, snapdom, or htmltoimage might be the most robust approach here, even though it feels like overkill. Thoughts?
I ended up going mostly with inline styles for my blocks (for lossyHTML export portability) and that solved big chunk of that issue for me.
The snap approach does feel like an overkill for me, maybe some more configurability like renderForDrag in block specs would allow me to wrap the component in a div setting all the css vars I need. And if someone wants to use snap2image they can too.
I put together a workaround for the oversized image preview when dragging blocks. Hope this helps, @YousefED!
IMPORTANT
This workaround relies on BlockNote's internal DOM classes and data-id attributes. Recheck those selectors and the drag behavior after upgrading BlockNote. Content persistence and block ordering remain handled by the existing editor and autosave logic.
The idea is to let BlockNote start the drag normally, then resize its preview using the dimensions of the blocks actually displayed in the editor. That way, images don't suddenly expand in the drag preview, and BlockNote still handles the drop and cleanup. Here's the code:
NOTE: When you use a custom schema, pass it to useBlockNoteEditor(yourSchema) in both buttons.
The preview keeps the editor's width, copies the rendered media dimensions, and clips its height at 240px (you can adjust that limit or remove it if you'd rather show the whole block). This only changes the drag preview.
One caveat:
This workaround relies on BlockNote's internal DOM classes and data-id attributes. Recheck those selectors and the drag behavior after upgrading BlockNote. Content persistence and block ordering remain handled by the existing editor and autosave logic.
Hopefully this gives us a useful starting point for a fix!
Activity
YousefED commentedon Jun 20, 2025
@nperez0111 I'm starting to think using a library like html2canvas, snapdom, or htmltoimage might be the most robust approach here, even though it feels like overkill. Thoughts?
kruszczynski commentedon Jun 21, 2025
I ended up going mostly with inline styles for my blocks (for lossyHTML export portability) and that solved big chunk of that issue for me.
The snap approach does feel like an overkill for me, maybe some more configurability like
renderForDragin block specs would allow me to wrap the component in a div setting all the css vars I need. And if someone wants to use snap2image they can too.nperez0111 commentedon Jun 25, 2025
While I would agree that it likely is overkill, it does look like htmltoimage is a pretty small lib ~5kb and I found the core function of it here: https://github.com/bubkoo/html-to-image/blob/master/src/util.ts#L221 Maybe can just pull in that approach and cut out the rest
Seems like snapdom uses the same approach: https://github.com/zumerlab/snapdom/blob/main/src/core/capture.js
fix(core): make drag previews render like the block they copy
fix(core): make drag previews render like the block they copy
batnieluyo commentedon Oct 13, 2026
¡Hi there!
I put together a workaround for the oversized image preview when dragging blocks. Hope this helps, @YousefED!
The idea is to let BlockNote start the drag normally, then resize its preview using the dimensions of the blocks actually displayed in the editor. That way, images don't suddenly expand in the drag preview, and BlockNote still handles the drop and cleanup. Here's the code:
The important part is the order in
onDragStart: callblockDragStartfirst so BlockNote creates the preview, then apply the sizing workaround.I also added a little styling for the preview:
To use the custom side menu, disable the default one and connect the controller inside existing editor view:
The preview keeps the editor's width, copies the rendered media dimensions, and clips its height at 240px (you can adjust that limit or remove it if you'd rather show the whole block). This only changes the drag preview.
One caveat:
Hopefully this gives us a useful starting point for a fix!
fix(core): display drag previews in Firefox and Safari (#3235)
nperez0111 commentedon Oct 27, 2026
Can you guys try out #3235 to let us know whether you think this solution is sufficient for your needs?