Popover component: Improve Visibility When Hitting Viewport Edge

[okmttdhr]

What problem does this address?

The Popover component in @wordpress/components does not currently provide a way to specify an offset when it meets the viewport edge. A popover appears cut off or unclear when positioned near the screen boundary.

This issue was observed in DataViews' settings dropdown. Although the dropdown is scrollable and remains functional, it is not visually clear that content is accessible via scrolling. Users may mistakenly believe that the menu is truncated instead of fully available.

This issue affects any UI that relies on Popover for dropdowns, modals, or floating panels.

What is your proposed solution?

• Expose a new prop in the Popover component, similar to the existing overflowPadding prop from Ariakit's popover component.
• Use this new prop in Popover to add a small offset when calculating max height, ensuring that popovers are never flush with the viewport edge.
• Allow DataViews (and other components relying on Popover) to leverage this enhancement, improving visibility without requiring manual workarounds.

[yogeshbhutkar]

Thanks for reporting the issue! I've made a corresponding PR here.

[mirka]

Taking a step back, I think we need to clarify what the desired visual outcome is here.

For example, this is the Options popover in the Editor, when the menu overflows and is flush with the bottom edge of the viewport:

Always show scroll bars	Show scroll bars when scrolling

You can imagine that an offset at the bottom is not going to help if the cutoff point just happens to be where a menu item ends. It will still look like the menu is just over. Only a scroll bar can indicate that there is more content. Or maybe some kind of down arrow overlay that appears when there is overflow.

On one hand, I think it's the user's responsibility to always keep scroll bars visible in their OS settings if they care about stuff like this. Hiding them will make them miss a ton of content in all sorts of apps and webpages, not just WP popovers!

On the other hand, I'd be interested if anybody has some clever solutions.

[ciampo]

Indicating to the user that the popover can be scrolled is definitely playing a factor, although that's a general "UI" problem and, as you mention, it's also the responsibility of the user.

For example, we had a similar conversation for the Tabs when scrolling horizontally and we ended up adding a gradient at the edges as a visual hint. Although I don't think that all scrolling containers in Gutenberg should have that.

[t-hamano]

I lean toward thinking that this is not a bug, but I'd like to see if we can close this issue as "Won't fix" or "Not a bug".

I would also like to discuss again whether there is any value in proceeding with #69555.

[ciampo]

I would also like to discuss again whether there is any value in proceeding with #69555.

That's a change that adds more flexibility to Popover, without breaking existing usages, and without really increasing the complexity of the implementation. IMO, that's a net improvement. Although I'd also understand if folks preferred not to ship something unless there's an actual need for it.

[stokesman]

I feel use of an option like that proposed by #69555 might help make the UI feel more polished because a popover hitting the viewport edge can lend to an impression that you should scroll the viewport (or an ancestor) to see the rest of it. Yet where that mostly bothers me are cases in which having the popover flipped would seem the more effective improvement. Here’s an example:

That’s not applicable to the popover mentioned in the OP where a padding might still be welcome. I also realize what I'm highlighting there might not be something our popover library has a solution for. I haven’t investigated.

[t-hamano]

That's a change that adds more flexibility to Popover, without breaking existing usages, and without really increasing the complexity of the implementation. IMO, that's a net improvement. Although I'd also understand if folks preferred not to ship something unless there's an actual need for it.

My concern is whether there are really any consumers who want to use this option to control the space.

Personally, I think it would be better to just always leave a small space at the edge of the viewport, i.e. subtract 8px or 16px from here, rather than introducing a new prop. I don't think any consumers would consider it a bug that the popover doesn't stick to the edge of the viewport 🤔

Or, close this issue as not a bug.

[ciampo]

These are all valid points, and I don't have a strong opinion.

I honestly don't know if consumers will ever want not to leave gap from the viewport. Personally, I just prefer to err on the side of offering more customization to the consumer for low-level components like Popover, especially if that doesn't come at a high cost in terms of implementation.

always leave a small space at the edge of the viewport

We could add a fixed 8px padding (like done in https://github.com/WordPress/gutenberg/pull/69555/files#diff-17616836f71aea95243b3f7b4846281ac2502d0bc9d09e13c555fac6d9c1441dR227) without adding an extra prop as an initial step.

whether there are really any consumers who want to use this option to control the space. [...] close this issue as not a bug.

That's also a potential way forward. I don't have strong opinions and I'm happy for y'all to agree on the next steps.

[t-hamano]

We could add a fixed "8px" padding (like done in https://github.com/WordPress/gutenberg/pull/69555/files#diff-17616836f71aea95243b3f7b4846281ac2502d0bc9d09e13c555fac6d9c1441dR227) without adding an extra prop as an initial step.

I support this approach.

[yogeshbhutkar]

Thank you all for the wonderful discussions!

We could add a fixed 8px padding (like done in https://github.com/WordPress/gutenberg/pull/69555/files#diff-17616836f71aea95243b3f7b4846281ac2502d0bc9d09e13c555fac6d9c1441dR227) without adding an extra prop as an initial step.

I’ve updated #69555 to reflect this approach.