Searchable Select: press Enter does not always select/toggle the focused item

[lixiaoyan]

Provide a general summary of the issue here

https://stackblitz.com/edit/rac-searchable-select-enter-issue?file=src%2FSelect.tsx

Open a searchable select, type 33 (or any two digits) quickly, and then press Enter. Repeat those steps.

Scree Record

Screen.Recording.2025-09-28.at.8.51.53.PM.mov

🤔 Expected Behavior?

Enter should always select(single)/toggle(multiple) the focused item.

😯 Current Behavior

Enter does nothing.

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

https://stackblitz.com/edit/rac-searchable-select-enter-issue?file=src%2FSelect.tsx

Version

1.12.2/3.0.0-nightly-df85b152a-250928

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

macOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[lixiaoyan]

Workaround: add onKeyDown to the <Input />

const state = useContext(SelectStateContext);

onKeyDown={(event) => {
  if (event.key === 'Enter') {
    event.preventDefault();
    if (
      state &&
      state.selectionManager.isFocused &&
      state.selectionManager.focusedKey
    ) {
      state.selectionManager.select(
        state.selectionManager.focusedKey,
      );
    }
  }
}}

[snowystinger]

I'm unable to reproduce in Chrome and Safari. I'm unable to run the example in Firefox at all.
It's hard to tell what's happening in that screen recording, I can't tell if/when Enter is being pressed.

[lixiaoyan]

@snowystinger I found the root cause of the problem.

Assume we have a select with value 33.

---

Step 1. Open select
useSelect -> focusedKey: 33 (the first selected item)
useAutocomplete -> activeDescendant: 33
useAutocomplete -> queuedActiveDescendant: 33

---

Step 2. Type 3
useSelect -> focusedKey: 3
useAutocomplete -> activeDescendant: 33 (because of delayNextActiveDescendant)
useAutocomplete -> queuedActiveDescendant: 3

In useSelectableItem, moveVirtualFocus moves the virtual focus to 3 while aria-activedescendant on the <input> remains 33.

---

Step 3. Type 3 again in 500ms
useSelect -> focusedKey: 33
useAutocomplete -> activeDescendant: 33
useAutocomplete -> queuedActiveDescendant: 3

moveVirtualFocus determines that the from (aria-activedescendant on the <input>) and to (focusedKey) are both 33, resulting in no focusin event being fired on the collection.

---

After 500ms
useSelect -> focusedKey: 33
useAutocomplete -> activeDescendant: 3
useAutocomplete -> queuedActiveDescendant: 3

---

To make moveVirtualFocus function properly, we may need another attribute on <input> that updates synchronously, besides aria-activedescendant.

[snowystinger]

Thanks for the additional information. It sounds like this might also be fixed or possibly made not an issue via RAC Select Type-ahead not working as per ARIA guidelines if we decide to do that. edit, I conflated two different issues, apologies for any confusion

[lixiaoyan]

@snowystinger But these are two completely different problems, correct? My problem is not related to typeahead at all. After typing 3 again, the input value is 33; pressing Enter does nothing since the item 3 is being filtered out.

[snowystinger]

Ah, sorry yes, I was thinking about the type ahead in relation to another topic and accidentally brought that in here. You are correct, this is not related. I'll update my comment