fix(SelectMenu): honour searchInput autofocus false when the menu opens

[IgorShevchik]

Ports 6caa6a95. Cursor moves to it, which is nuxt/ui v4 HEAD — the sync is caught up again.

The bug

FocusScope trapped focuses the first focusable descendant when the menu opens, and that descendant is the search input — regardless of what searchInput.autofocus says. So :search-input="{ autofocus: false }" had no effect on open, and on a touch device the virtual keyboard came up anyway. The fix intercepts the scope's own event:

function onMountAutoFocus(event: Event) {
  if (searchInputProps.value.autofocus === false) {
    event.preventDefault()
  }
}

Applies verbatim. Our pre-image is upstream's down to the insertion point — onClear() immediately followed by const viewportRef = useTemplateRef('viewportRef') — and the docs page carries the same anchor paragraph with ### Content after it. Only the standing ui → b24ui class-binding rewrite applies.

The tests cover less than they look, and that is the finding

Upstream's two cases port structurally, with one selector change: this fork puts data-slot="input" on the control itself where upstream puts it on a wrapper, so [data-slot="input"] input matches nothing here and becomes input[data-slot="input"]. Left as upstream wrote it, the assertion fails on an empty wrapper rather than on the behaviour — red for the wrong reason.

The ported handler is not covered here. Measured, not assumed:

mutation	result
remove @mount-auto-focus (revert the port)	both green
invert the condition to !== false	both green
preventDefault() unconditionally	both green

Instrumenting onMountAutoFocus with a counter explains it: called zero times. Reka's FocusScope does not emit mountAutoFocus under happy-dom, so no test in this suite can reach that path.

What actually focuses the input here, read stage by stage:

stage	document.activeElement
after mount	BODY
after flushPromises	DIV[data-slot=root]
after a macrotask	INPUT[data-slot=input] — and only when autofocus is not false

Focus never lands on the input via FocusScope in this environment. It arrives later from Input.vue's own autofocus, and with autofocus: false that path simply does not fire — which is why upstream's symptom does not reproduce under happy-dom at all.

They are not vacuous, though — they guard a different thing. They pin the observable contract (searchInput: { autofocus: false } leaves the search input unfocused on open) through the Input.vue path. Verified by rewriting props.autofocus to true in Input.vue, which turns one of them red.

The port is still right. In a real browser FocusScope does focus that descendant, so upstream's bug reproduces here too; only the test environment cannot run the path. The handler is correct by construction and costs nothing. What is not claimed is coverage — the comment on the test block says so in as many words, so a later reader does not mistake green for verified.

Verification

lint · typecheck · build (3.86 MB) · docs:generate · test — 340 files, 7710 passed, 6 skipped · test:module.

docs:generate is in there because this commit touches a docs page and the ci gate never builds the docs site, so a break there would surface in the deploy rather than in the PR.

---

Generated by Claude Code