Popover combined with Menu is not flipped when the content doesn't fit

[LittleCreamSoda]

Provide a general summary of the issue here

Recently I've encountered a weird behaviour of the Popover component. Having both Menu component and any other html element inside of a popover results in an incorrect calculation of popover's maxHeight and position. You can see that while opening a popover near the bottom of a viewport.

https://github.com/user-attachments/assets/eb781cfc-be97-4e57-b828-11a172519446

🤔 Expected Behavior?

Popover position should be flipped to the opposite direction and all of the popover's content should be visible.

😯 Current Behavior

Part of the Popover's content is not visible

💁 Possible Solution

Probably have something to do with calculatePositionInternal function

🔦 Context

I have a list of items each having a button that opens up a popover with menu and some extra information. I've noticed that items which are close to the page bottom rendering their popover incorrectly (at the bottom of the trigger) instead of the trigger's top. As a result part of the popover is not visible for a user. This behaviour is observed only when the Popover has both the Menu and any other element inside of it. If the Popover has only the Menu component or any layout without a Menu everything works just fine

🖥️ Steps to Reproduce

https://codesandbox.io/p/sandbox/react-aria-popover-6y7k6k

Version

react-aria-components: 1.7.1

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

macOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[LFDanLu]

I believe this is because of MenuTrigger providing the Menu's scroll ref as the Popover's scrollRef here, resulting in the wrong ref being used to calculate if flipping should happen. Will need to poke around to see if this breaks scroll anchoring or if we could just always use the overlayRef in that line in calculatePosition

[suyash5053]

Just curious, instead of considering the scrollSize as scrollNode here, can't we consider height?

[LFDanLu]

At a glance it seems like we could do that, would just need to test carefully in case there were any edge cases that we were previously accounting for