A deferred focus-leave from a menu's dismissal unmounts the same menu when it reopens within 50 ms

Current state, 2026-09-15. Fixed by PR #18720, with the design below. This body is the record; the thread below it is history.

The defect

A floating menu.List that is hidden and then shown again remounts, then gets taken down about 40 ms later with no user action. It's the same instance throughout (setConfigs({hidden: true}), then ({hidden: false})), and it ends at menuFocus: false, mounted: false, hidden: true.

Repro: test/playwright/component/menu/SpawnAnimation.spec.mjs › a dismissed and reopened instance is cleaned up and re-arms failed 5–7 times in 60 serial repeats when this was filed, and once in CI, in the components job on PR #18325. On dev@03219a75b7 it passed 60 of 60. That arm reopens only after polling for the removed node, and Playwright's first poll interval is 100 ms, which likely puts the reopen past the 50 ms gap. Reopening 0, 15, 30 or 45 ms after the node is gone failed 59 of 60 on the same tree.

The mechanism, measured

1. The dismissal removes the focused menu from the DOM. The browser fires a native focusout, which reaches the app worker as a message.
2. manager.Focus#onFocusout defers delivery by maxFocusInOutGap (50 ms) and captures the component path as ids (src/manager/Focus.mjs).
3. The reopen remounts the same instance, with the same id, 8–16 ms after hidden: false. It requests focus asynchronously (component.Base#afterSetMounted → focus()). Its focusin has not reached the manager when the timer fires: lastFocusInDate was measured 10–18 ms older than lastFocusOutDate.
4. The timer fires 51–54 ms after the dismissal. The #18299 guard passes, because no newer focusout exists, and the ids resolve to the remounted instance.
5. menu.List#onFocusLeave takes the !data.relatedTarget branch and sets menuFocus = false, which makes afterSetMenuFocus unmount the menu.

A MutationObserver shows REMOVED > ADDED > REMOVED on every failure.

The reopened menu still holds menuFocus: true: hiding a component whose parent is not document.body removes its DOM through the parent's update (component.Base#hide), which never runs menu.List#unmount(). It also keeps mounted: true, because VdomLifecycle#unmountRemovedChildren skips floating children.

Ruled out

The fix

The worker only sees the order in which events arrive. The order in which they happened exists only on the main thread, at dispatch, so the stamp is added there.

• DeltaUpdates#removeNode records the id it is removing for the duration of remove(), and DomEvents#onFocusOut stamps a focusout raised inside that call with removedNodeId. No other focusout changes, so other focus consumers see the field only on a removal.
• manager.Focus#isRemovedFloatingShownAgain: a pending leave is not delivered when its removed node is a floating component that is shown again by the time the leave comes due. A floating component requests focus whenever it mounts (component.Base#afterSetMounted), so its new mount reports its own focus.
• Every other leave is delivered as before: a focusout without the stamp, a removed component that is still hidden, and a component that is not floating.

Contract Ledger

focusout.data.removedNodeId: String is a new consumed field on the focusout payload the main thread sends to the app worker. It is additive and optional: it appears only on a focusout the engine's own node removal raised. Verified against PR #18720 at f30ba0ee4b.

manager.DomEvent forwards the payload object as-is (it clones per listener with Neo.clone(data, true, true)), so the field needs no transport change. Nothing outside manager.Focus reads it.

Acceptance Criteria

• SpawnAnimation.spec.mjs › a dismissed and reopened instance is cleaned up and re-arms passes 60 serial repeats with zero failures.
• Red-first against the mechanism: an arm that delivers a leave raised against the previous mount to the remounted menu fails before the fix and passes after, without waiting on the race.
• Legitimate dismissals still dismiss: outside pointer (#17825), Escape, document blur and the leaf-click cascade, each named with the arm that covers it.
• No instrumentation is committed. Heavy probes perturb this race: per-transition stack capture took the repro from 7/60 to 0/30.

Notes

• Instrument on the worker side. A main-realm focusin/focusout listener stays silent here, because the lifecycle runs in the app worker.
• Keep probes cheap. getConfigs on failure costs nothing. A MutationObserver on the body lowered the rate to 2/60, so read its shape, not its rate.
• Adjacent, not this defect: the manager.Focus dispatch reuses one data object across every component in the path, so a handler that retains it sees it change.

Related

#18215 (the arm that surfaced it) · #18299 / PR #18301 (the superseded-focusout fix) · #17825 (outside-pointer dismissal) · PR #18720 (the fix)