Keyboard behavior
Every key the widget responds to, and why focus never leaves the input.
The widget follows the combobox pattern: focus stays in the text input the entire time, and the keyboard moves a highlight over the results rather than moving focus onto them.
Why focus stays in the input
Moving focus onto each result as you press ↓ would fire a blur/focus cycle on every keystroke and confuse screen reader users mid-navigation. Instead, the input keeps focus throughout, and aria-activedescendant points at the currently highlighted result — see Accessibility for how this is exposed to assistive technology.
Typing while a result is highlighted
Typing a character while a result is highlighted always continues the query in the input — it never gets captured by the highlighted row. Only the keys listed above are intercepted; every other keystroke reaches the input normally, including while composing CJK input (see IME behavior).
Mobile
The mobile sheet keeps the same ↑/↓/↵ behavior for an attached hardware keyboard, and adds a persistent, always-visible Cancel control as the touch equivalent of esc.