unable to use keyboard navigation on dropdown opened via mouse click

[christianvogt]

Describe the issue. What is the expected and unexpected behavior?
When using keyboard navigation to open a Dropdown menu, then first item gets selected and navigation within the dropdown menu can be done using the up and down arrow keys.

This same behavior isn't present when the Dropdown menu is opened via mouse click.

Expect Dropdown menu to behave similar to default browser select menus:
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select

Please provide the steps to reproduce. Feel free to link CodeSandbox or another tool.
https://patternfly-react.surge.sh/documentation/react/components/dropdown
Same experience with the Select component:
https://patternfly-react.surge.sh/documentation/react/components/select

• Click a Dropdown menu and press arrow keys. No navigation.
• Select a Dropdown menu and press enter key. Navigation of the menu is enabled.

Is this a bug or enhancement? If this issue is a bug, is this issue blocking you or is there a work-around?
Bug

What is your product and what release version are you targeting?
OpenShift Console

[tlabaj]

cc @jessiehuff

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[christianvogt]

bump

[jgiardino]

Early on when implementing the dropdown, we intentionally did not place focus in the menu on mouse click. I think the very first implementation had this, and we were getting feedback that this was unexpected behavior for mouse users and was causing confusion. People were seeing the focus state on the first menu item and thought that the first item was automatically selected. So this behavior was later addressed in #1075. (cc'ing @beanh66 as she was the primary contact sharing this feedback, but it was a long time ago so no guarantees that she remembers 😉 )

The only way I think you could pull this off is to have the dropdown component to shift focus to the menu on an arrow key keypress, but not handling focus until an arrow keypress, to avoid the issue described above. I wouldn't know if this is possible, though.

It’s also worth noting that Firefox doesn’t shift focus on mouse click (at least on a mac), whereas Chrome does. Just something to keep in mind when testing how focus is handled relative to mouse interactions across different browsers.

[christianvogt]

Personally, I dislike seeing the focus indicator on any component when navigating via mouse. However I expect the last item I interact with to have focus and therefore using keyboard nav from that point. This is the type of behavior component libraries like material UI support. See css :focus-visible, https://github.com/WICG/focus-visible for more info.

On my mac I tried: chrome, edge, FF, safari
Every one of these browsers let me use the keyboard nav to navigate the select menu immediately after opening via click in this page: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select
Perhaps it's a setting my mac but it works for me.

[jgiardino]

Personally, I dislike seeing the focus indicator on any component when navigating via mouse. However I expect the last item I interact with to have focus and therefore using keyboard nav from that point. This is the type of behavior component libraries like material UI support. See css :focus-visible, https://github.com/WICG/focus-visible for more info.

Parts of this comment sound like a potential issue for core (the parts about using :focus-visible). I will defer to @mcoker on that one. ;-)

Regarding the part about "the last item I interact with to have focus", this behavior varies from browser to browser, component to component, element to element. For example, clicking a button in FF (at least on my mac) will not shift focus to the button, but in Chrome is does. But in any browser, form controls will grab focus (similar to what you described about the <select> menu), and then custom components are also capable of managing focus.

In general, my preference is to not override default browser behavior unless there is a really good justification to do so. So with a basic button, I'd wouldn't add anything in to shift focus to the button. However, your point about the select menu reminds me of another preference, which is to base interaction patterns on existing controls that users are already really familiar with. I think it's a relatively safe assumption that users would try to interact with dropdown menus the same way they interact with <select> menus. So if it's possible to handle the case where a user clicked the toggle, then used the arrow key, then I'm totally not opposed to that interaction pattern.

My 2 cents on this one though, is I would question the priority of this update, because I don't know that it is a common interaction pattern to switch from mouse to keyboard, and the user isn't blocked from interacting with the control. I’m not sure what the repo defines as a bug, but I also raise the question of whether this should be marked as an enhancement instead. So if it's an easy fix 👍 but if not 🤷

[christianvogt]

Well I'll leave it to patternfly to classify this as a bug or enhancement and whether to implement it or not. But it would be nice to see this fixed.

Here's a few big players that follow this behavior:

• html select
• ibm carbon design system
• bootstrap
• material-ui
• semantic ui
• ant (select)

[jgiardino]

👍

Thanks for sharing the examples! It's always helpful to see how components/systems handle things.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[christianvogt]

bump