[W4Checklist] [Due for payment 2025-05-20] [$250] Cmd+K Navigation Fails to Open Chat After Desktop Update

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @mallenexpensify
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Update Desktop (possibly just close then reopen too)
2. Type cmd+k
3. Start typing a name of a contact
4. Press return key once the contact is highlighted

Expected Result:

Opens highlighted/selected chat with person

Actual Result:

Nothing happens, have to mouse to name and click on trackpad to open

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

2025-04-23_10-02-15.mp4

logs-2025-04-23 08_02_40.009.txt

Profile_trace_for_9.1.31-2.cpuprofile

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021915316750024963357
• Upwork Job ID: 1915316750024963357
• Last Price Increase: 2025-04-24
• Automatic offers:
• thelullabyy | Contributor | 107113235

Issue Owner

Current Issue Owner: @strepanier03

[melvin-bot]

Triggered auto assignment to @strepanier03 (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[shubham1206agra]

Screen.Recording.2025-04-23.at.4.04.44.PM.mov

Able to repro this. This happens only once when I open the App.

[linhvovan29546]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-23 12:25:46 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Cmd+K Navigation Fails to Open Chat After Desktop Update

What is the root cause of that problem?

In the #56948 We updated SearchAutocompleteList, we have disableKeyboardShortcuts={!shouldSubscribeToArrowKeyEvents}. This disables the Enter shortcut when shouldSubscribeToArrowKeyEvents is either false or undefined. That flag default is undefined. And, in SearchRouter, we render the SearchAutocompleteList without that flag, which leading to the disableKeyboardShortcuts is true, then nothing happen when press enter

App/src/components/Search/SearchAutocompleteList.tsx

Lines 600 to 601 in 8a9ecc6

	shouldSubscribeToArrowKeyEvents={shouldSubscribeToArrowKeyEvents}
	disableKeyboardShortcuts={!shouldSubscribeToArrowKeyEvents}

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 822 to 828 in 806e231

	useKeyboardShortcut(CONST.KEYBOARD_SHORTCUTS.ENTER, selectFocusedOption, {
	captureOnInputs: true,
	shouldBubble: !flattenedSections.allOptions.at(focusedIndex) || focusedIndex === -1,
	shouldStopPropagation,
	shouldPreventDefault,
	isActive: !disableKeyboardShortcuts && !disableEnterShortcut && isFocused && focusedIndex >= 0,
	});

What changes do you think we should make in order to solve the problem?

We have two options:

Option 1:
Set shouldSubscribeToArrowKeyEvents = true by default in SearchAutocompleteList, as the issue in that PR seems to an edge case.

App/src/components/Search/SearchAutocompleteList.tsx

Lines 130 to 138 in 8a9ecc6

	function SearchAutocompleteList(
	{
	autocompleteQueryValue,
	searchQueryItem,
	getAdditionalSections,
	onListItemPress,
	setTextQuery,
	updateAutocompleteSubstitutions,
	shouldSubscribeToArrowKeyEvents,

shouldSubscribeToArrowKeyEvents = true

Option 2:
Explicitly pass shouldSubscribeToArrowKeyEvents={true} from SearchRouter.

App/src/components/Search/SearchRouter/SearchRouter.tsx

Lines 348 to 350 in 8a9ecc6

	<SearchAutocompleteList
	autocompleteQueryValue={autocompleteQueryValue || textInputValue}
	searchQueryItem={searchQueryItem}

                    <SearchAutocompleteList
                        shouldSubscribeToArrowKeyEvents

We can check other places, like this one, to see if a similar issue exists.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

I think automated tests are not necessary in this case since we're making shouldSubscribeToArrowKeyEvents default to true. If a value of false is passed explicitly, it would be intentional.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[ishakakkad]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-23 15:58:56 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Item does not select using keyboard navigation, when first time open the search dialog on chat page.

What is the root cause of that problem?

When the search dialog is opened for the first time, the search input loses focus when arrow keys are pressed. As a result, pressing the Enter key does not trigger item selection. However, this issue does not occur when the dialog is opened subsequently—the search input retains focus during arrow key navigation, and Enter works as expected. This issue is occurred because of this condition.

On the first render, areOptionsInitialized is false. It only becomes true after a component re-render triggered by options loading. During this initial phase, pressing arrow keys causes the search input to lose focus, leading to the unexpected behavior.

On subsequent openings of the search dialog, the options have already been initialized, so areOptionsInitialized remains true from the start. This allows arrow key navigation without affecting the input focus, and Enter correctly selects the highlighted item.

What changes do you think we should make in order to solve the problem?

Solution 1

To fix this issue we need to add areOptionsInitialized check before loading search input as well. We can make following changes here

const {areOptionsInitialized} = useOptionsList(); 

 {isRecentSearchesDataLoaded && areOptionsInitialized && (
    <>
        <SearchInputSelectionWrapper

Note: Also, we need to check other places where we used SearchAutocompleteList and make the same changes if needed.

Solution 2

We can add following code inside SearchRouter

useLayoutEffect(() => {
if (textInputRef.current && textInputRef.current.isFocused()) {
        setTimeout(() => {
            textInputRef?.current?.blur();
            textInputRef?.current?.focus();
        }, 0);
    }
}, [textInputRef.current]);

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

UI bug so NA

What alternative solutions did you explore? (Optional)

Initialize options when the provider is mounted here (not ideal solution)

useEffect(() => {
        if (!isLoadingApp && !areOptionsInitialized.current && personalDetails && reports) {
            const optionLists = createOptionList(personalDetails, reports);
            setOptions({
                reports: optionLists.reports,
                personalDetails: optionLists.personalDetails,
            });
            areOptionsInitialized.current = true;
        }
    }, [isLoadingApp, personalDetails, reports]);

[thelullabyy]

Proposal

Please re-state the problem that we are trying to solve in this issue.

• When a user opens the search route for the first time and types a query, pressing "Enter" does nothing. The expected behavior is that the top search result is selected, but instead, users must manually click with the mouse or trackpad to proceed.

What is the root cause of that problem?

• This issue occurs only the first time a user opens the search route. When the search route opens, the search input is automatically focused:
  

  App/src/components/Search/SearchAutocompleteList.tsx

  Line 577 in 18f248c

  areOptionsInitialized && (

• This triggers the onFocus callback in SearchAutocompleteInput.tsx:
  

  App/src/components/Search/SearchAutocompleteInput.tsx

  Lines 214 to 218 in 18f248c

  	onFocus={() => {
  	onFocus?.();
  	autocompleteListRef?.current?.updateExternalTextInputFocus(true);
  	focusedSharedValue.set(true);
  	}}

• At this point, autocompleteListRef is still null because areOptionsInitialized is false:
  

  App/src/components/Search/SearchAutocompleteList.tsx

  Line 577 in 18f248c

  areOptionsInitialized && (

• Due to this, updateExternalTextInputFocus is not called:
  

  App/src/components/SelectionList/BaseSelectionList.tsx

  Lines 811 to 813 in 18f248c

  	const updateExternalTextInputFocus = useCallback((isTextInputFocused: boolean) => {
  	isTextInputFocusedRef.current = isTextInputFocused;
  	}, []);

• As a result, isTextInputFocusedRef.current remains false, causing shouldSyncFocus to evaluate as true:
  

  App/src/components/SelectionList/BaseSelectionList.tsx

  Line 589 in 18f248c

  shouldSyncFocus={!isTextInputFocusedRef.current && hasKeyBeenPressed.current}

• This triggers the useSyncFocus hook, which blurs the input:
  

  App/src/hooks/useSyncFocus/useSyncFocusImplementation.ts

  Line 33 in 18f248c

  ref.current?.focus({preventScroll: true});

• Since the input is no longer focused, pressing "Enter" doesn't trigger selection logic in SearchRouter.tsx:
  

  App/src/components/Search/SearchRouter/SearchRouter.tsx

  Lines 327 to 336 in 18f248c

  	onSubmit={() => {
  	const focusedOption = listRef.current?.getFocusedOption();
  	if (!focusedOption) {
  	submitSearch(textInputValue);
  	return;
  	}
  	onListItemPress(focusedOption);
  	}}

What changes do you think we should make in order to solve the problem?

• Pass textInputRef to the SearchAutocompleteList component:
  

  App/src/components/Search/SearchRouter/SearchRouter.tsx

  Line 348 in 18f248c

  <SearchAutocompleteList

  <SearchAutocompleteList ... textInputRef={textInputRef} />;

• In SearchAutocompleteList.tsx, use this ref inside the onLayout handler:
  

  App/src/components/Search/SearchAutocompleteList.tsx

  Line 589 in 18f248c

  onLayout={() => {

  onLayout={() => {
      ...
      ref.current?.updateExternalTextInputFocus?.(textInputRef.current.isFocused())
  }}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• NA

What alternative solutions did you explore? (Optional)

• Introduced a potential fallback skeleton component SearchInputSelectionWrapperSkeleton. Then conditionally render either the skeleton or the actual SearchInputSelectionWrapper based on areOptionsInitialized:
  

  App/src/components/Search/SearchRouter/SearchRouter.tsx

  Line 323 in 18f248c

  <SearchInputSelectionWrapper

  areOptionsInitialized ? <SearchInputSelectionWrapper /> : <SearchInputSelectionWrapperSkeleton />;

• SearchInputSelectionWrapperSkeleton can be discussed by design team.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021915316750024963357