A search that resolves after the user has dismissed the dropdown reopens it.
Nothing cancels an in-flight search when the search session ends, and handleSearchResult's guard cannot tell the difference: after the dropdown closes textValue is '', and a default search's query is '' too, so a late result passes the guard and re-renders the suggestions.
Reproduced
On a real relation picker in lime-webclient (Deal field on a to-do, real API, 400ms network throttle to widen the window): Esc-Esc at t=3920ms; the first Esc fired search('') at t=3922, it resolved at t=4328 — after the second Esc had dismissed the dropdown — and the suggestions re-rendered at t=4402. Same end state observed without throttling.
A related case, same missing concept: after Esc the dropdown is closed but focus stays in the input, so edit mode is still true. A Backspace removal then starts a search and the dropdown pops back open. Reproduced in lime-webclient's admin Authentication Log user picker: pick a user, Esc, Backspace twice → the dropdown reopened with the full user list.
Suggested direction
The picker has no explicit notion of whether a search session is open — it infers it from focus and an empty query, and both inferences are wrong after Esc. A session counter, bumped in clearInputField and checked in handleSearchResult, would let stale results be dropped; the same concept would let the removal refresh ask "is a session open?" instead of "is the input focused?".
Found while reviewing #4223. Reproductions by @john-traas.
A search that resolves after the user has dismissed the dropdown reopens it.
Nothing cancels an in-flight search when the search session ends, and
handleSearchResult's guard cannot tell the difference: after the dropdown closestextValueis'', and a default search's query is''too, so a late result passes the guard and re-renders the suggestions.Reproduced
On a real relation picker in lime-webclient (Deal field on a to-do, real API, 400ms network throttle to widen the window): Esc-Esc at t=3920ms; the first Esc fired
search('')at t=3922, it resolved at t=4328 — after the second Esc had dismissed the dropdown — and the suggestions re-rendered at t=4402. Same end state observed without throttling.A related case, same missing concept: after Esc the dropdown is closed but focus stays in the input, so edit mode is still true. A Backspace removal then starts a search and the dropdown pops back open. Reproduced in lime-webclient's admin Authentication Log user picker: pick a user, Esc, Backspace twice → the dropdown reopened with the full user list.
Suggested direction
The picker has no explicit notion of whether a search session is open — it infers it from focus and an empty query, and both inferences are wrong after Esc. A session counter, bumped in
clearInputFieldand checked inhandleSearchResult, would let stale results be dropped; the same concept would let the removal refresh ask "is a session open?" instead of "is the input focused?".Found while reviewing #4223. Reproductions by @john-traas.