Clicking on another overlay trigger or focusable element does not focus the element when an overlay was already open

[jeroenwienk]

🐛 Bug Report

In the storybook example https://reactspectrum.blob.core.windows.net/reactspectrum/9ea100232a1a4a868a6d29056ec6eed958e796b4/storybook/index.html?path=/story/usemenu--double-menu-fires-oninteractoutside I expect when I open the first menu and click on the second one the first one closes and the seconds one opens but this does not happen. Also if you try to focus the input field you have to click twice if you have one of the menus open.

🤔 Expected Behavior

I expect the next menu to open or the input to be focused immediatly on a overlay close.

😯 Current Behavior

The first menu closes and you have to click again to open the second menu or focus the input.

💁 Possible Solution

🔦 Context

💻 Code Sample

🌍 Your Environment

Software	Version(s)
react-aria	3.7.1
react-stately	3.6.1
Browser	Chrome 91.0.4472.124
Operating System	Windows 10

🧢 Your Company/Team

🕷 Tracking Issue (optional)

[snowystinger]

Hey there, thanks for opening the issue. This is intentional, we have another piece coming down the line to disable interactions such as hover for elements in the background to make it a little more clear. We chose to make this change before that one due to a pesky bug where multiple overlays could be opened at the same time and determined that it was important to close that bug. This behavior also matches the native behavior of menus/selects on macOS and most browsers.

[jeroenwienk]

Hey there, thanks for opening the issue. This is intentional, we have another piece coming down the line to disable interactions such as hover for elements in the background to make it a little more clear. We chose to make this change before that one due to a pesky bug where multiple overlays could be opened at the same time and determined that it was important to close that bug. This behavior also matches the native behavior of menus/selects on macOS and most browsers.

It just feels so unnatural to me. For example if you have a header with 3 action buttons that open different stuff it is more fluent if you hit the next button that it just opens the next menu instead of only closing the current one. In Chrome opening the settings menu or clicking on your avatar is an instant action.

I tried some menus in Windows explorer and they all just open instantly when the previous one was a menu. Only on inputs/searchfields you have to click twice.

I've checked https://material-ui.com/components/popover/ this seems to be doing the same as implemented in react aria.

It seems like it is the wild west what this behavior is supposed to be.

I'm not sure if I understand the technical difficulty here but would it not be possible to define this behavior in useOverlay (opt in or out)?

[devongovett]

Appears to be a macOS vs Windows difference. You can try the native behavior here: https://codepen.io/devongovett/pen/MWmWoNK

On macOS, clicking on another select or input does not open or focus that element, it just closes the menu. On windows, it immediately opens/focuses the element.

[armandabric]

On Ubuntu we have to close the opened element before interacting with the next one.

I'm not sure these is a consensus on this kind of interaction. Maybe adding a props of triggers allowed to do quick interaction could be enough to let library user to choose the behavior.

[shouze]

This is not very nice in terms of UX when you have 2 or more select/dropdown next each other (think about booking a hotel use case : destination / guests / dates of stay). I have twice Clicks to do. Airbnb & Booking.com don't have this issue whatever the browser or operating system.

Definitely need some props to configure that behavior. @snowystinger How can we help on this topic?

[snowystinger]

We used to have behavior like this, however, it led to several difficult-to-solve race conditions where previous popovers wouldn't close and you'd have multiple open at once. This is not something that is accessible and solving that was our number one priority. The reason for it was that some popovers have an animation to close and some do not.
We took inspiration from the Mac-native behavior, which behaves exactly as you describe.

If we're going to support both, then we'd need to solve the race conditions. We have a couple of stories in storybook that can help check if these are working as expected.
You can start looking here #1970 there's a lot of history on this topic.
And here is where we tried to fix the race https://github.com/adobe/react-spectrum/pull/1510/files without success

It's entirely possible that supporting this is beyond the capability of the current API without a breaking change. If this is the case, we'll need to discuss how/if we want to move forward on it.

[devongovett]

I think we will not be supporting this anytime soon, so I'm going to close this. Closing without triggering another element is an accessibility feature, and just plain usability feature. Otherwise users need to be very careful about where they click so they don't trigger unintentional interactions. You can see issues like #7283 where this was not working correctly for some examples of why this is important.