Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Combobox with autocomplete="both" filters out too many options #2347

Open
jattasNI opened this issue Aug 15, 2024 · 3 comments · May be fixed by #2376
Open

Combobox with autocomplete="both" filters out too many options #2347

jattasNI opened this issue Aug 15, 2024 · 3 comments · May be fixed by #2376
Assignees
Labels
blocked Blocked on a third-party issue bug Something isn't working

Comments

@jattasNI
Copy link
Contributor

🐛 Bug Report

When the combobox is set to autocomplete="both", it is changing its value to equal the item that autocompletes. This causes other items that should match the entered text to be filtered out.

💻 Repro or Code Sample

  1. In the Storybook combobox page, set autocomplete to both and choose "Many options"
  2. Type "S"
Screen.Recording.2024-08-15.at.9.02.05.AM.mov

🤔 Expected Behavior

All of the "Sue..." items should be visible

😯 Current Behavior

Only the first matching item, "Sue (1)", is visible.

💁 Possible Solution

@atmgrifter00 says

So I think I have an understanding of why the combobox behaves the way it does, and it basically involves us putting in some workarounds to make the combobox behave more like a text field, which FAST wasn't ready (or willing) to do. Unfortunately, we just had an oversight resulting in this bug, which the fix for is, annoyingly enough, likely going to involve some more state management for the filter text.

🔦 Context

This was originally reported as an SLE bug: Bug 2670859: Nimble combo box | Drop down does not filter the matched text correctly

That will likely be fixed by migrating to a filterable select. Another possible workaround is to use autocomplete="list".

🌍 Your Environment

Not environment-dependent

@jattasNI jattasNI added bug Something isn't working triage New issue that needs to be reviewed labels Aug 15, 2024
@rajsite
Copy link
Member

rajsite commented Aug 15, 2024

My understanding of our intended direction is to align the filter-mode / autocomplete modes with the select. We shouldn't have an autocomplete mode both anymore, effectively just list with improved filtering that aligns with select.

Is there a specific use-case for autocomplete mode both or mode inline? Can we pre-emptively mark it deprecated and say only list should be used?

@jattasNI
Copy link
Contributor Author

jattasNI commented Aug 20, 2024

Agreement from the team that we can deprecate both. To fix this we should

  1. update the enum and docs
  2. update clients to move away from both.

1 is low priority backlog work, 2 is worth doing sooner

@jattasNI jattasNI removed the triage New issue that needs to be reviewed label Aug 20, 2024
@jattasNI jattasNI self-assigned this Sep 4, 2024
@jattasNI
Copy link
Contributor Author

jattasNI commented Sep 4, 2024

I started working on item 1 in #2376 and item 2 in this SLE PR. But I ran into a bug with the remaining autocomplete mode "list": #2378. Temporarily marking this blocked because I don't think we want to tell clients to migrate to "list" with that known bug still open.

@jattasNI jattasNI added the blocked Blocked on a third-party issue label Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Blocked on a third-party issue bug Something isn't working
Projects
Status: Current Iteration
Development

Successfully merging a pull request may close this issue.

2 participants