Using setPointerCapture for Press Events

[bdow]

Hi all,

Have there been any discussion around using setPointerCapture for the custom PressEvents?
We have a use case in which a Select Field is used within a Modal. The Modal and the Select Field's menu use an OverlayContainer for positioning. We set shouldSelectOnPressUp: false, in our useOption hook because we've noticed sometimes the menu can load on top of the SelectField (if the viewport is short enough), which would cause an immediate selection of the option if not set.

Example of the layout I am describing:

When a user selects an option that is outside of the Modal's contents (on top of the 'underlay') such as option "Employee 6" in the above example, then the onPointerDown event selects the option (due to shouldSelectOnPressUp: false). That event immediately removes the menu and the subsequent onPointerUp event is triggered on the Modal's underlay, which causes the Modal to close. I have been trying to figure out a way around this, such as using shouldCloseOnInteractOutside in the Modal's useOverlay hook, but that only gives me access to the element the Press event is triggered on without a way of figuring out where the pointer event originated from.

The two issues I described (1. Having to use shouldSelectOnPressUp: false to avoid accidentally selecting menu option if menu is displayed on top of trigger, and 2. The subsequent onPointerUp triggering on the underlay) could possibly be mitigated by using setPointerCapture in the onPointerDown event. Any thoughts?

[snowystinger]

Hey! It might be a good idea to address the menu rendering over the picker button. What are you using to do the positioning? Selecting on Press start instead of end may lead to some accidental selections. (I'm quite clumsy with my thumb on a mobile device)

[bdow]

Thanks for the reply @snowystinger. We are currently using useOverlayPosition for positioning the menu relative to the trigger. We enable shouldFlip: true, which we want incase the trigger element is at the bottom of the screen. If we set shouldFlip: false, then it wouldn't ever render on top of the trigger element, but it might also render off screen. To add in another wrinkle, we disable the browser's native scrolling and only scroll a specific area of our application. This means that the Overlays are always removed when the scroll event is fired. So when we really need to set shouldFlip: true otherwise, if the Listbox/Menu is rendered beneath the trigger element placed at the bottom of the screen, then the user has no way of accessing it, because when they scroll to put it in view it will disappear.

[bdow]

Following up to this, the reason why the menu might show up on top of the trigger element is because we set a fixed height on our menu list. The fixed height is required because of the virtualization (React-Virtuoso) library we use for super long lists. Rather than having that height set based on the available space in the viewport, we were hard coding it. That wound us up in this area where the menu can show on top of the trigger element.

[bdow]

More follow up, I was able to further fix this by utilizing the maxHeight value set in the useOverlayPosition to define the height for the virtualized list. This now prevents the Menu from showing on top of the trigger element and we can go back to shouldSelectOnPressUp: true. Which in turns fixes our issue with accidentally triggering onPointerUp on the Modal's underlay.

[snowystinger]

Glad to hear it! Just confirming then, nothing else to do here for now? And THANK YOU for the detailed explanation of what you've done to address it. I can't express that enough.

[bdow]

Yes, confirming nothing else to do here now. I appreciate your quick feedback! Thanks for providing the libraries and support!