material-ui icon indicating copy to clipboard operation
material-ui copied to clipboard

[Autocomplete] highlighted index doesn't get reset if options length is unchanged

Open ViktorZhurbin opened this issue 1 year ago • 9 comments

Duplicates

  • [X] I have searched the existing issues

Latest version

  • [X] I have tested the latest version

Steps to reproduce 🕹

Link to live example: https://stackblitz.com/edit/react-taee4w?file=Demo.tsx

Steps:

  1. With empty input box, use kb arrows to select 3rd option and hit Enter
  2. Press arrow down and observe which option is highlighted

Current behavior 😯

4th option is highlighted

Expected behavior 🤔

1st option should be highlighted

Context 🔦

If you remove limit from createFilterOptions, it works as expected. Likely connected to the deps array of syncHighlightedIndex which includes filteredOptions.length

Your environment 🌎

No response

ViktorZhurbin avatar Dec 12 '23 10:12 ViktorZhurbin

It's an expected behavior. When you use a keyboard to select multiple items, you don't want to be taken back to the beginning after selecting the first one and have to move down by arrow keys again to reach the next option.

michaldudak avatar Dec 22 '23 13:12 michaldudak

When you use a keyboard to select multiple items, you don't want to be taken back to the beginning after selecting the first one and have to move down by arrow keys again to reach the next option.

@michaldudak That's exactly what happens with filterSelectedOptions: true, and it makes sense to me - selected option is removed from the list, and you start over.

But it doesn't happen with filterSelectedOptions: true when I limit the number of displayed options through filterOptions.

With filterSelectedOptions: true going back to the beginning makes more sense to me personally. And I expected the same behaviour in both cases.

I've updated the demo to make the ifference clearer - https://stackblitz.com/edit/react-taee4w?file=Demo.tsx

ViktorZhurbin avatar Dec 23 '23 08:12 ViktorZhurbin

OK, so it's inconsistent based on limiting the number of displayed options, I see. I'd say that the behavior with limit is better (as you can continue selecting more options after the first one without having to move from the top again), but we lack the highlight being visible after pressing Enter in both cases.

michaldudak avatar Dec 27 '23 10:12 michaldudak

hey can i work on this issue?

1CUNHA1 avatar Mar 08 '24 15:03 1CUNHA1

I will work on this issue :)

1CUNHA1 avatar Mar 14 '24 23:03 1CUNHA1

@1CUNHA1, if the fix is contained only within Material UI (so the useAutocomplete hook) is not modified, then we'll likely be able to merge and release it. However, things may be more problematic if you have to touch MUI Base. We recently moved the development of it to the new repo and are working on changing the component API there. We likely won't release any new version from that repo soon (as in before Q3).

Feel free to investigate the issue and let me know about your findings.

cc @DiegoAndai, @mnajdova

michaldudak avatar Mar 15 '24 07:03 michaldudak

Hey @michaldudak , as you expected the bug came from the "filteredOptions.length" dependency in "syncHighlightedIndex" in mui-base. The problem was that when the list had a limit smaller than the total number of options, when an option was selected the size of the list didn't change. For the same reason, the "syncHighlightedIndex" function wasn't called and the index wasn't reset. To solve the bug, I changed the "filteredOptions.length" dependency to "filteredOptions", so that whenever there is a change in the "filteredOptions" list, such as removing an element, the function will be called and the index reset.

1CUNHA1 avatar Apr 03 '24 16:04 1CUNHA1

So, as I mentioned, we'll have to wait with the fix until we get to implement the Autocomplete in the Base UI repo.

michaldudak avatar Apr 10 '24 19:04 michaldudak

Hey, when i made the chage some tests started to fail. Do i have to change the tests or can i open a pr anyway?

1CUNHA1 avatar Apr 26 '24 09:04 1CUNHA1