Change of focus/blur events in input components?

[ray007]

I'm wondering, if the emitted update:focused events had some change from vuetify 3 to version 4.

I have a table, which on cell-click (or dblclick) renders an edit control in the cell, and which changes back to display the formatted value on blur.
But since upgrading to vuetify 4, I often get a blur immediately after starting the edit, or opening the menu of a select, ...

Anybody an idea what changed?

[mg1986jp]

This sounds like a known side effect of Vuetify 4's migration to native <input> focus management. In v3, input components used a custom internal focused state and emitted update:focused on their own schedule. In v4, several components switched to relying more on the actual DOM focus/blur events — which means things like opening a v-select menu can cause the underlying input to lose DOM focus momentarily, triggering update:focused = false.

For the inline-edit-in-table pattern specifically, what's probably happening:

• User clicks cell → your code renders the edit component
• The component mounts and grabs focus
• A menu opens (or an internal overlay appears), focus shifts to the menu element
• Your blur handler fires and swaps back to display mode

Two things that fixed this for me in similar setups:

1. Debounce the blur handler — don't switch back to display mode immediately, give it 100-200ms and check if focus moved to a child element (the menu) rather than outside the cell entirely:

function onBlur() {
  setTimeout(() => {
    if (!cellRef.value?.contains(document.activeElement)) {
      editing.value = false
    }
  }, 150)
}

2. Use @update:menu on v-select instead of update:focused — if you're using select/autocomplete components, the menu open/close event is more reliable than focus for knowing when the user is "done editing".

Are you seeing this with all input types (v-text-field, v-select, v-autocomplete) or only specific ones?

[ray007]

Main problem was with v-select and friends, need to take another look at the rest.
Not yet sure if I got all my problems sorted, but the delayed blur handling already helped a lot, thanks for that.

Any idea what's the plan for the future here? Should we use update:focused instead of the native events?
Which currently has the same problem... seems the controls with menu need some love.

[mg1986jp]

@ray007 Yeah unfortunately update:focused has the same underlying issue for v-select — it's driven by the internal isFocused ref which tracks DOM focusin/focusout on the component tree. When the menu opens, focus can briefly leave the component's DOM boundary (especially if the overlay is teleported), and isFocused flips to false before the focus repair kicks in.

Looking at the current source, onFocusout checks relatedTarget to see if focus moved within the component, and there's a useFocusRepair that tries to recover orphaned focus (when relatedTarget is null and activeElement falls to document.body). But there's a timing gap — if relatedTarget points to something outside the component briefly during menu transition, isFocused goes false before repair can run.

So for now the debounced blur approach is probably still the most reliable workaround for the inline-edit-in-table pattern. I don't think there's an official stance from the Vuetify team on this yet — might be worth opening an issue specifically about v-select focus stability in v4, linking this discussion.