[Autocomplete] Differentiate hover & keyboard states

With the current implementation, if you hover over an option, and then move your cursor outside of the option menu, the last option you were hovering over remains highlighted. I would like to remove this highlight programmatically.

• I have searched the issues of this repository and believe that this is not a duplicate.

#20615 is related, but it has been closed.

Summary 💡

If setHighlightedIndex were exposed (along with the option to pass null for the index to remove the highlighted option), I could call setHighlightedIndex({ index: null}) to remove the highlight. Alternatively, if Autocomplete had a clearHighlight or removeHighlight prop that was simply a boolean, Autocomplete could check its status and call setHighlightedIndex({ index: null}) internally if it was ever set to true. Or, a removeHighlightOnExit prop could be set.

Examples 🌈

As you can see below, after moving the cursor outside of the menu, pressing “Enter” searches for the text in the input - “material ui” rather than the previously highlighted option “material ui textfield.”

Motivation 🔦

With the current implementation, if you hover over an option, and then move your cursor outside of the option menu, the last option you were hovering over remains highlighted. This means that pressing “Enter” automatically selects the last selected option. I would like to implement functionality similar to Google’s search, so that if you if press “Enter” it redirects you to a search results page. I added a custom onMouseLeave function to ListboxProps that removes [data-focus] from the highlighted option (to remove its styling) and removes [aria-activedescendant] from the input element when hovering outside of the menu. Then, in my Autocomplete onChange function, I’m checking for the existence of [aria-activedescendant] on the input. If it doesn’t exist, it means the cursor is outside of the menu and it returns (thus not selecting anything), and allows the form to submit. This is working fine; however, if a user hovers outside of the menu (removing the highlight) and presses the down arrow on their keyboard, the option below the previously highlighted option is selected, rather than the first option as one would expect. There is no method to reset the highlighted index.

[sanders54]

I am encountering the same issue. It’s difficult to hack around the issue, and most other autocomplete that has free text (like Google) seem to follow the behaviour of differentiating the hover and keyboard state. Would love a update.

[eps1lon]

@eps1lon On macOS, the hover & keyboard focus shares the same state, it’s even true for a native <select>.

Sure, but what I meant was not the visual states but the actual “cursors”: mouse cursor and keyboard cursor. So it’s not the states that look the same but the cursors that are linked. Though a native select does work that way it seems.

I think we should rather implement the behavior where mouse and keyboard have different cursors. That’s how google.com works, or the autocomplete in chromes navigation bar, or the autocomplete for labels on github. It’s surprising to me why the native select works the way it does. Though autocomplete and <select> are different UI patterns so I don’t think they need to have the same cursor behavior.