Select in Toolbar breaks keyboard navigation

[unional]

Provide a general summary of the issue here

Toolbar uses {ArrowLeft} and {ArrowRight} to move around items.

Select also use them to select items.

So when Select is placed inside a Toolbar, the keyboard navigation of Toolbar is broken.

🤔 Expected Behavior?

Toolbar should work.

Used to be working fine in 1.9.0

😯 Current Behavior

Stuck on the Select.

💁 Possible Solution

Disable the left/right navigation of Select.

🔦 Context

No response

🖥️ Steps to Reproduce

https://codesandbox.io/p/sandbox/late-surf-c3w6cp

Version

1.11.0

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

Palo Alto Networks

🕷 Tracking Issue

No response

[snowystinger]

Thanks for the issue. Unfortunately select is not supported at this time for the same reason as text field. It makes use of all the arrow keys.

#7937 (comment)

If I recall correctly, we followed the native implementation of select for that behaviour since it's not defined in the aria patterns page.

[unional]

Um... that would be a problem. TextField in Toolbar we can probably say it is not the right usage (but there are also counter example of it. I'm thinking about a find field in the toolbar of traditional Windows application).

But Select in Toolbar is a pretty common use case. Pretty much the most used pattern besides simple buttons.

Maybe add a props in Select to disable that particular behavior?

[unional]

Intuitively I feel like the Keyboard selection for Select should be activated after user press {Enter} or {Space} to "focus into the components (the popover list)", and then we can use arrow key to select.

[unional]

If I recall correctly, we followed the native implementation of select for that behaviour since it's not defined in the aria patterns page.

I just tried it on Chrome.
Native select react to {Space}, {UpArrow} and {DownArrow} and open the selection.
It does nothing with {LeftArrow} and {DownArrow}.

It also works as expected when placed in Toolbar.

When <Toolbar orientation="vertical">...</Toolbar>,
the keyboard interaction still works "as expected":

• When pressing {UpArrow} and {DownArrow} when the focus is on the select, focus is moved to the next item in the Toolbar. i.e. the select dropdown is not opened.
• When pressing {Space}, the dropdown is opened and user can select the options using {UpArrow} and {DownArrow}.

[unional]

FYI, due to #8635,
I can't even pin react-aria-components to 1.9.0 to get the working behavior.

[snowystinger]

We could consider a prop or something on the context to change the behaviour.

I was on my phone when I last replied so was unable to verify the left/right arrow when the select is closed. It looks like it comes from Firefox. I didn't see the behaviour on Safari or Chrome on MacOS. I'll double check with the team to make sure this is something we want to support.

Can you revert your lockfile? or can you patch the behaviour while we discuss? apologies for the difficulty

[snowystinger]

Coworker reminded me of this previous issue #1265 so it looks like the behaviour really comes from windows

And here's some previous work we tried to do to support this #5080 (comment)

We have made some fixes to FocusScope since then, so this may be more possible now as an approach that avoids context/props and instead relies on capturing listeners.

This is probably also related to some of the work we're currently exploring with Table/GridList "edit-mode". Will need to see if the approaches can be coordinated.

[unional]

Can you revert your lockfile?

It's not our lockfile. That we can revert.
The issue this when the consumer of our package (our styled component library), they will get 3.30.0 because react-aria-components is using ^3.29.0.

Coworker reminded me of this previous issue #1265

Arrow Left / Right

• OSX: selects next/previous entry
• Windows: selects next/previous entry

That's interesting. Atm I'm on my mac Sequoia 15.5 and Chrome doesn't do that.
Let me check on Safari and Firefox

Either way that does conflict with the Toolbar behavior.

UPDATE:

• Safari works like Chrome
• Firefox 140.0.2 does behave that way. My company does not allow firefox update, so can't verify the behavior on 141.

[snowystinger]

My earlier assumption was wrong that it was the left/arrow keys interferring. It broke in https://www.npmjs.com/package/react-aria-components/v/3.0.0-nightly-d312e0a20-250607 which corresponds to this commit 431241e#diff-1b4bb1d7973d81d8ac44ea584d527bfbe742409b0783b2087c06bc356af0365dL761

Looks like our change to detection of visible elements is responsible. Looking into how to we can address it.