fix: Menu overflows

[matthewlipski]

While we handle overflows for Tippys and Mantine Menu.Dropdown components to some extent (i.e. flipping the position when there's no space), for very small viewports where there's no space an any available position, the element goes beyond the viewport. Unfortunately, this is not something easily fixed with the use of Menu props, so this PR adds a new hook which dynamically adjusts maxHeight for Menu.Dropdown components when they're rendered. This hooks is used by almost all UI elements which use a Menu (slash menu, color picker, and formatting toolbar dropdown).

Closes #339

[vercel]

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

Name	Status	Preview	Updated (UTC)
blocknote-website	✅ Ready (Inspect)	Visit Preview	Sep 22, 2023 4:21pm

[YousefED]

@matthewlipski, can't we set a max-height to for example 100vh using CSS? won't that solve the problem?

Also, in Floating UI I think this becomes easier: https://floating-ui.com/docs/size

[matthewlipski]

@matthewlipski, can't we set a max-height to for example 100vh using CSS? won't that solve the problem?

Also, in Floating UI I think this becomes easier: https://floating-ui.com/docs/size

Not really, since this would make the dropdown the same height as the viewport, but in most cases the top of the dropdown is not in the same place as the top of the viewport, so it would still overflow.

[dukesx]

How about also adding a constrained Dropdown height and let the inside elements as overflow scroll?

[YousefED]

@matthewlipski, can't we set a max-height to for example 100vh using CSS? won't that solve the problem?
Also, in Floating UI I think this becomes easier: https://floating-ui.com/docs/size

Not really, since this would make the dropdown the same height as the viewport, but in most cases the top of the dropdown is not in the same place as the top of the viewport, so it would still overflow.

Got it. Is the solution at the bottom of this page https://mantine.dev/core/scroll-area/ possible with menus? If so, that would be more of a Mantine-style fix I think

How about also adding a constrained Dropdown height and let the inside elements as overflow scroll?

@dukesx you mean a fixed height?

[dukesx]

@YousefED yes exactly. I figure that trying to make it responsive through javascript is just a bottleneck.

[matthewlipski]

@matthewlipski, can't we set a max-height to for example 100vh using CSS? won't that solve the problem?
Also, in Floating UI I think this becomes easier: https://floating-ui.com/docs/size

Not really, since this would make the dropdown the same height as the viewport, but in most cases the top of the dropdown is not in the same place as the top of the viewport, so it would still overflow.

Got it. Is the solution at the bottom of this page https://mantine.dev/core/scroll-area/ possible with menus? If so, that would be more of a Mantine-style fix I think

How about also adding a constrained Dropdown height and let the inside elements as overflow scroll?

@dukesx you mean a fixed height?

I played around with Scrollarea.Autosize but unfortunately it doesn't seem to be able to replace the JS logic :/ It will make the element inside it scrollable once it goes beyond a predetermined max height, but we're still left with the issue of calculating that max height (which is currently done using the custom hook). Using 100vh still won't work as the dropdown doesn't always span from the very top to the very bottom of the viewport, depending on the selected block's position.

Also yeah this seems really easy to do with FloatingUI, it's frustrating that Mantine heavily limits the middleware customization (can only set { flip: boolean, shift: boolean, inline: boolean }), even though it seems to use FloatingUI itself.

[YousefED]

Would be nice if we can get rid of the setTimeout somehow. For now, let's add a comment why this "hack" is necessary

Looking at the source code, it's possible that in the latest mantine (v7) you can pass a ref to menu.dropdown but for now this PR is ok imo