fix(VCombobox): filter matching items when opening first time (#21900)

[jcjp]

Description

• Not automatically filtered on load even if search value has value

fixes: #21900

Markup:

<template>
  <v-app>
    <v-container>
      <v-combobox
        v-model="msg"
        :items="['Colorado', 'Florida', 'Georgia', 'Texas', 'Wyoming', 'California']"
      />
    </v-container>
  </v-app>
</template>

<script setup>
  import { ref } from 'vue'

  const msg = ref('Cali')
</script>

[J-Sek]

When placed side-by-side with VSelect and VAutocomplete, new behavior feels a bit off. - before: I can type 44 (no match) but still re-open full list

• after: list does not appear and it might feel unexpected/broken

demo

The original problem is the difference between typing the value and setting it programmatically. It would be best to target this specifically and leave the rest as-is.

[J-Sek]

Alternative fix:

watch(model, value => {
  if (!props.multiple && !hasSelectionSlot.value) {
-    +search.value = value[0]?.title ?? ''
+    search.value = value[0]?.title ?? ''
  }
-})
+}, { immediate: true })

Breaks some tests... I don't have time to dig it this week. @jcjp, can you evaluate it?

[jcjp]

Alternative fix:

watch(model, value => {
  if (!props.multiple && !hasSelectionSlot.value) {
-    +search.value = value[0]?.title ?? ''
+    search.value = value[0]?.title ?? ''
  }
-})
+}, { immediate: true })

Breaks some tests... I don't have time to dig it this week. @jcjp, can you evaluate it?

I updated the solution, we are running into test issues whenever we try to update the search.value directly on the watch so instead I just emit an update:search for the new value do you think about this, is it okay? I updated my sample code above to use your example on your demo link.

No errors on the test as well, here is the result of the unit test.

VCombobox run vitest VCombobox

Full run run vitest

[J-Sek]

emit(.. does not break the tests, but also does not seem to have the desired effect - i.e. does not filter the list.

Anyway, my suggestion has the same problem as the previous attempt. Menu does not appear when there is no match (e.g. for msg = ref("xx")) which is inconsistent with typing those letters manually. We need to dig deeper.

[jcjp]

emit(.. does not break the tests, but also does not seem to have the desired effect - i.e. does not filter the list.

Anyway, my suggestion has the same problem as the previous attempt. Menu does not appear when there is no match (e.g. for msg = ref("xx")) which is inconsistent with typing those letters manually. We need to dig deeper.

I recorded my test, I want to clarify if is this not the desired behavior? EDIT: You are right as per my checking will dig deeper thanks Jacek!

I have updated my solution, it seems that the target behavior that we need to replicate is already living in VAutocomplete. Let me know if this works, I also run the test and it passes.

[J-Sek]

@jcjp, I have added a test against regression (re-opening menu after typing cal shows all options) and a second one for the new behavior we'd like to observe. Currently, both fail because re-opening does not preserve narrowed options.

Initially, I wrote those tests to be based on keyboard interactions (Tab » type » Escape » ArrowDown), but it looks like the options are only preserved if the user clicks outside... Clicking on the menu icon, Tab, Escape - all other methods of closing - seem to clear the "search". With your changes, click-outside + reopen aligns with all of the other methods, but I don't think it is a desired behavior... It is a tough battle. If you can make these new tests pass, we could merge it and handle the re-opening inconsistency later. Ideally, it should not matter if the user opens the menu for the first or n-th time with any of the methods.

[jcjp]

@jcjp, I have added a test against regression (re-opening menu after typing cal shows all options) and a second one for the new behavior we'd like to observe. Currently, both fail because re-opening does not preserve narrowed options.

Initially, I wrote those tests to be based on keyboard interactions (Tab » type » Escape » ArrowDown), but it looks like the options are only preserved if the user clicks outside... Clicking on the menu icon, Tab, Escape - all other methods of closing - seem to clear the "search". With your changes, click-outside + reopen aligns with all of the other methods, but I don't think it is a desired behavior... It is a tough battle. If you can make these new tests pass, we could merge it and handle the re-opening inconsistency later. Ideally, it should not matter if the user opens the menu for the first or n-th time with any of the methods.

I updated the solution and looks the issue is fixed, thanks for reviewing and adding the test.

[J-Sek]

Overall, it looks great. Just anticipating a bug report below.

Recording

Screencast.from.2025-08-23.19-58-20.webm

[johnleider]

Overall, it looks great. Just anticipating a bug report below.

Recording
Screencast.from.2025-08-23.19-58-20.webm

Recording won't load for me.

[J-Sek]

@johnleider, when the text does not match any of the list options, every 2nd time I open the menu it either shows all options or a "No data available". So I am clicking menu icon to toggle it on/off and it consistently cycles between both of these results.

Screenshots

It would be great if we could avoid it.

[johnleider]

The video is loading for me now, thank you.

I fixed the bug but there is a flicker animation happening when we blur the input field, looks annoying let me know if you guys are okay with this.

[J-Sek]

• opening first time with non-matching value should show all options (consistently, not only on subsequent attempts)
• when I defer loading options (e.g. 2s delay), open, close, wait 2s, open - shows all items, not the matching one

I will attempt a cleanup. There are too many boolean flags scattered all over the place and it is making the whole thing very brittle.

[J-Sek]

@jcjp, the last commit has changed quite a lot.
Could you please double-check for any regression?

[jcjp]

@jcjp, the last commit has changed quite a lot. Could you please double-check for any regression?

I did the test manually looks good thank you for your help on the flicker issue!