wip: remove some formattingtoolbar listeners

[YousefED]

I'm investigating if we can remove these listeners or fix them somewhere else.

It seems like floating-ui is covering a lot of the things these methods have been designed for. I think it would be nice to simplify this (and see "background" below for more motivation).

Bugs / issues
Can you help look into what bugs could arise from this? So far, I've encountered two changes:

• Formatting toolbar doesn't "flip" position any more when scrolling
• when dragging / dropping a block, the formatting toolbar appears. I think we need to solve this differently (i.e.: maybe we should just clear the selection when dragging blocks? Why is the dragged block selected at all?)
• ...

Background
The reason I'm investigating it is so that we can potentially render UI elements (shadcn / floating ui etc) within a Portal. Currently, the BlurHandler in FormattingToolbar is not compatible with this as it expects events to come from within a specific dom root.

This would fix two issues:

• UI elements cut when container has overflow hidden #1255 by enabling portalling
• compatibility with ShadCN components that use a Portal (currently, we require users to comment out Portals in their components, see note at bottom of docs)

[vercel]

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

Name	Status	Preview	Updated (UTC)
blocknote	✅ Ready (Inspect)	Visit Preview	Nov 17, 2024 9:02pm
blocknote-website	✅ Ready (Inspect)	Visit Preview	Nov 17, 2024 9:02pm

[matthewlipski]

Ok, I think I know why we're seeing the 2 bugs mentioned:

Bug 1

In useUIElementPositioning, we update the Floating UI virtual element DOMRect to referencePos, whenever referencePos changes. The virtual element DOMRect is also used to calculate Floating UI middleware (in this case flip). For each UI element,referencePos is taken from the current plugin state, which we usually update in event listeners (scroll being one of them in this case). Therefore, we needed the scroll listener was to make sure that the referencePos is always updated to the correct DOMRect.

However, it would be more sensible if instead of manually updating referencePos, we instead expose a getReferencePos function. That way, whenever Floating UI needs to update the position, it can call editor.uiElement.getReferencePos, instead of using whatever's in the plugin state. This will guarantee that Floating UI and it's middleware are always using the correct reference DOMRect to determine the final position.

@YousefED Since this requires a refactor for all UI elements, I think we should wait with this for the 0.19.3 release.

Bug 2

This is because we use ProseMirror's built-in logic for drag & drop within the editor, which is based on selection. We do set the clipboard data, but seems like PM doesn't use that to clear the blocks from the original position. So if we don't set the selection on dragstart, the blocks do get inserted at the new position correctly since the clipboard data is correct, but only the content in the old selection is cleared - not the blocks in the original position.

In theory this shouldn't be too difficult to fix, since we just have to handle the drop event and clear the original blocks ourselves.

[matthewlipski]

See comment above

[YousefED]

Thanks! Did you also dig into whether there could be other bugs or why it might be unsafe to remove the listeners?