Why is the Popover modal by default?

[loicplaire]

Hi!

First of all, I want to thank you for the amazing work you are doing! We are using react-aria in our components library and it helped us immensely so far!

I am currently building a Popover component using usePopover and wondered why the popover is modal by default.
Most of the examples I have seen in other component libraries have non-modal Popover by default, i.e. you can scroll and interact with the page when a popover is opened:

• https://reakit.io/docs/popover/
• https://reshaped.so/content/docs/components/popover
• https://www.radix-ui.com/docs/primitives/components/popover
• and so on.

I can also see, that most of your pickers are modal (such as https://react-spectrum.adobe.com/react-spectrum/Picker.html) which seems a little bit unusual.

I can make the popover non-modal by using the isNonModal prop but I wonder why you recommend against it in the props documentation when, from my understanding, it is very common for a popover to be non-modal.

Would you be able to clarify this for me? Thank you so much!

[devongovett]

The reasons are mostly related to React portals.

1. Because overlays are rendered in a portal at the end of the document body, there may be a lot of elements between the original trigger element and the popover. This can make it very difficult for screen reader users (especially on mobile) to move between the trigger and the overlay. For this reason, we hide all elements outside the overlay from screen reader users which keeps their focus contained within the overlay.
2. As for scrolling, this was a recent change in the last release. The new behavior of preventing scrolling outside popovers/menus actually matches native behavior (at least on macOS). If you try a native <select> for example, you can see this. Previously we would close the popover when the surrounding element scrolled, which caused some usability issues (e.g. accidentally closing). Repositioning the popover so it always follows the trigger on scroll is also not possible in all cases (e.g. if the trigger is scrolled out of view, but the popover pops out of the scrolling container). It can also be quite janky to do this. The simplest solution to this is to prevent scrolling, which keeps the user's focus on the overlay.
3. Clicking outside popovers is also prevented so that when the user is trying to dismiss the popover, they don't accidentally activate something else. This also matches the behavior of a native <select> or menu on macOS.

I can make the popover non-modal by using the isNonModal prop

We strongly recommend against this, because it will cause problems for screen reader users as described in (1) above. ComboBox is an example of a component that specifically handles this case. It hides all elements except both the overlay and the input, since the user's focus remains on the input while the popover is open. The user also needs to interact with the input (e.g. moving the cursor) while the menu is open, so we don't prevent clicking outside in this case. We are also forced to close the menu on scroll in this case to avoid the other issues described above.

Hopefully this clarifies the behavior. If you do have a case where scrolling or interaction outside a popover is expected, you can always drop down to the lower level hooks that usePopover is built with, and compose them together yourself, but proceed with caution.

[sarimarton]

@devongovett I remember you mentioned edge cases and hard implementation, but react-laag handles this case. Also, couldn't the new CSS Anchor Positioning provide a bug-free implementation?

[kruzliak-juraj]

I understand the worry of accidental scroll, yet it is a need in certain use cases, which is why I think should be covered.

Regarding it not being possible, I am not sure what do you mean by that. The examples in the original post show it is possible, the trigger and the popover both just scroll away on scroll, while being still opened when the user scrolls back in the view. The same behavior as in the original examples can be found in MUI poper, or NextUI popover, or Mantine popover, and I could go on. Besides, I would think (I may be wrong) that some kind of detection of if it is out of viewport could be done that would close it in such case, but I do not really see the need for that in my opinion. The feature of it behaving like in all the examples is satisfactory.

Oddly enough, I just realized that I want the same behavior as your Tooltip has when it is controlled, as can be seen in this quick mock: https://codesandbox.io/p/sandbox/elegant-tom-w54n64 - so I guess this gives me another option on how to implement it. It is odd that it works there, but I guess you did not expect it to be used in such a way, which makes me think it would be risky to use it this way in case you change it there as well.

As I said, I just want to plea for you to reconsider it and/or give it as an additional behavior option. If you want to keep the current implementation, I will understand, but we will have to either create a more complex solution (or use useTooltip api :)) on our end or reconsider using this library.

Edit: after more testing, it seems that controlled Popover works the same as the Tooltip so I guess I will play around with that for now and see if it creates some issues somewhere else that I am not aware of.

[devongovett]

It's not an edge case. One of the main reasons to use a popover is that it pops "out" of whatever container might be clipping it, be that a dialog, scrolling list, etc. Like this:

If the user were to scroll that container such that the trigger is out of view, there's no longer anything for the popover to attach to:

This problem exists no matter what library you use. Most of the examples you pointed to work because the trigger element and the popover are both inside the same scrollable area (the body), so when you scroll the trigger out of view the popover also goes out of view. If the popover pops out of a nested scrollable area, then you will see this problem. The solutions are either to hide the popover on scroll or prevent scrolling. We think the latter is a better UX.

[kruzliak-juraj]

Thank you for the explanation and the time, that makes sense. So it is ok only if I could guarantee that both elements will be the body scrollable area. Thank you very much, I have much to discuss with the team :)

[kruzliak-juraj]

One last quick note, after testing scroll area in scroll area with popover in different libraries, it seems they opted in for re-calculating the position on scroll.
Radix example - https://codesandbox.io/p/sandbox/radix-primitives-tailwind-forked-xtpngy
MUI example - https://codesandbox.io/p/sandbox/mui-5-forked-g3hdfl
Mantine example - https://codesandbox.io/p/sandbox/mantine-v7-forked-fvzntk

[borispetrovdev]

I’d also think scrolling behind a popover should be par for the course, and I can’t help but point out the irony of the GitHub comments interface itself exhibiting this behavior:

ScreenRecording_01-17-2025.18-13-01_1.mov

That said, I appreciate that the React Aria team is grappling with genuine tradeoffs, and that the option of dropping down to the lower level hooks is reasonable.