[Due for payment 2025-10-27] [Due for payment 2025-08-20] [$250] Android - Search - Keyboard is not automatically opened despite input being focused.

[jponikarchuk]

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: 9.1.79-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/6469116&group_by=cases:section_id&group_order=asc&group_id=229066
Email or phone of affected tester (no customers): ibellicotest+1282@gmail.com
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 - Android 12 - Chrome (Hybrid App)
App Component: Search

Action Performed:

1. Open the Expensify app.
2. Tap on the search icon on the top right corner.
3. Note that input is focused and keyboard is automatically opened.
4. Return to "Inbox" and tap on the search icon again.
5. Note that input is focused, but keyboard is not automatically opened.

Expected Result:

When opening search list, keyboard should be automatically opened, as the input is focused.

Actual Result:

Keyboard is automatically opened only the first time that search is opened. The next times, input is focused but keyboard is not automatically opened anymore.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021943531379525651048
• Upwork Job ID: 1943531379525651048
• Last Price Increase: 2025-07-18
• Automatic offers:
• allgandalf | Contributor | 108119807
• Krishna2323 | Contributor | 108207495

Issue Owner

Current Issue Owner: @jliexpensify

[melvin-bot]

Triggered auto assignment to @jliexpensify (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.

[Eskalifer1]

Proposal

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

Android - Search - Keyboard is not automatically opened despite input being focused

What is the root cause of that problem?

The problem is specific to Android.
Our input has autoFocus: true

App/src/components/Search/SearchAutocompleteInput.tsx

Line 86 in 90a1901

autoFocus = true,

Android may not open the keyboard if the input is already in focus and tries to focus again, as well as if there are any animations (for example, opening a modal window)

In our case, due to the fact that the input has autofocus, the keyboard does not open at first because there is an animation, and then it does not open because the inpt is already in focus.

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

We need to pass autoFocus - false, and call focus in useEffect:

    useEffect(() => {
        InteractionManager.runAfterInteractions(() => {
            textInputRef.current?.focus();
        });
    }, []);

Additionally we can do it only for Android if needed

And if needed we can move tis logic to this component:

App/src/components/Search/SearchInputSelectionWrapper/index.native.tsx

Lines 7 to 16 in 90a1901

	function SearchInputSelectionWrapper(props: SearchAutocompleteInputProps, ref: ForwardedRef<BaseTextInputRef>) {
	return (
	<SearchAutocompleteInput
	ref={ref}
	// eslint-disable-next-line react/jsx-props-no-spreading
	{...props}
	selection={undefined}
	/>
	);
	}

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

None

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.

[rohit9625]

Proposal

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

Android - Search - The keyboard is automatically opened only the first time the search is opened. The next time, input is focused, but the keyboard is not automatically opened.

What is the root cause of that problem?

This issue is happening after the changes made in the PR #65250, i.e., we are now using a custom ReanimatedModal instead of ReactNativeModal for narrow layouts:

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

Line 38 in ccfdb74

shouldUseReanimatedModal={shouldUseNarrowLayout}

The ReanimatedModal is designed to provide smooth entrance/exit animations using Reanimated’s Keyframe API. It uses a Container component, which is responsible for animations and rendering children(TextInput and other components) passed to it.

Internally, the modal’s lifecycle is driven by three state variables:

• isVisibleState: whether the modal should be shown at all
• isTransitioning: whether an open/close animation is currently running
• isContainerOpen: whether the animation has completed and the modal content is fully visible

Here’s where the problem happens:

• When isVisible becomes true, ReanimatedModal sets isVisibleState to true and starts the opening animation.
• The Container mounts immediately (based on isVisibleState) — so its children (like TextInput) also mount immediately.
• The TextInput uses autoFocus={true} at `SearchRouter:
  

  App/src/components/Search/SearchAutocompleteInput.tsx

  Line 209 in d9c9140

  autoFocus={autoFocus}

• When autoFocus={true} is set, React Native tries to focus the input immediately when it mounts.
• However, on Android, if the focus request happens before the modal’s view hierarchy is fully mounted or its opening animation finishes, the operating system may ignore the request to open the soft keyboard.

Hence, with ReanimatedModal, the modal’s container animates into view. But the TextInput actually mounts as soon as isVisibleState is true — before the animation finishes.

• So autoFocus fires while the modal’s container is still transitioning, not fully visible.
• Some OS keyboards (especially on Android) silently ignore focus requests in this half-visible state.

It's a known issue with Modals with animations where autoFocus can be unreliable as mentioned in this comment.

Why this does not break on the first render?

• On the very first mount, the modal’s container, backdrop, and input all appear for the first time.
• There is no prior hierarchy or animation to wait for — the input’s autoFocus lines up naturally with the fresh view.

Observe that on first render, the TextInput gains focus after a delay, and on subsequent renders, it is focused even before the screen is transitioned completely. There's a very small difference:

Screen_recording_20250711_013507.mp4

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

• Set autoFocus to false on the TextInput to prevent it from trying to focus too early.

• Hoist the textInputRef at the SearchRounterModal and pass it down to the SearchRouter so that we can control focus manually at root level:
  

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

  Lines 47 to 51 in d451e08

  	<SearchRouter
  	onRouterClose={closeSearchRouter}
  	shouldHideInputCaret={shouldHideInputCaret}
  	isSearchRouterDisplayed={isSearchRouterDisplayed}
  	/>

  + const textInputRef = useRef<AnimatedTextInputRef>(null);
          <SearchRouter
  +          textInputRef={textInputRef}

  Also, need to update the SearchRouterProps to accept textInputRef and remove the defined textInputRef from SearchRouter component:

      type SearchRouterProps = {
  +     textInputRef: React.RefObject<AnimatedTextInputRef | null>;
         onRouterClose: () => void;
    // SearchRouter function
  - const textInputRef = useRef<AnimatedTextInputRef>(null);

• Use the modal’s onModalShow prop at SearchRouterModal to focus the TextInput as this onModalShow is called after animation ends:

  <Modal
  // Other props
  onModalHide={() => setShouldHideInputCaret(isMobileWebIOS)}
  onModalShow={() => {
      textInputRef.current?.focus();
      setShouldHideInputCaret(false)
  }}

Note: This solution doesn't work if we don't set autoFocus={false} at SearchAutocompleteInput component.

Results:

After_Fix_Keyboard_Focus.mp4

Note: The above solution fixes the issue but it seems like the textInput is gaining focus after a longer delay. To address this, consider the alternative solution please or just remove the shouldUseReanimatedModal prop, added in linked PR completely, which defaults to false.

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

None, it's a UI platform specific UI issue.

What alternative solutions did you explore? (Optional)

1. Since, the onModalShow is executed after a quite long delay (which I think is due to the debug build), we can make use of useFocusEffect hook to focus the TextInput as soon as the SearchRouter gain focus. We just need to add this code at the SearchRouter component:

useFocusEffect(
    useCallback(() => {
        textInputRef.current?.focus();
    }, [])
);

Note: We don't need any other changes in above case, just remember to set autoFocus={false} otherwise it also won't work due to conflict with autoFocus.

Results:

After_Fix_Keyboard_Focus_2.mp4

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.

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @c3024 (External)

[jliexpensify]

Able to repro on Pixel 7

[Krishna2323]

Proposal

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

Android - Search - Keyboard is not automatically opened despite input being focused.

What is the root cause of that problem?

• SearchRouterModal uses ReanimatedModal which has animationInTiming of 300ms but the modal children components are rendered as soon as the animation starts.
  

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

  Line 38 in 4dbbb24

  shouldUseReanimatedModal={shouldUseNarrowLayout}

  
  

  App/src/components/Modal/ReanimatedModal/index.tsx

  Lines 15 to 20 in 4dbbb24

  	function ReanimatedModal({
  	testID,
  	animationInDelay,
  	animationInTiming = 300,
  	animationOutTiming = 300,
  	animationIn = 'fadeIn',

• We have set the autoFocus prop for the text input to true which focuses the input on componentDidMount, but at this time the modal animation is still in progress which is why the keyboard is ignored.
  

  App/src/components/Search/SearchAutocompleteInput.tsx

  Line 86 in 4dbbb24

  autoFocus = true,

  
  

  App/src/components/Search/SearchAutocompleteInput.tsx

  Line 209 in 4dbbb24

  autoFocus={autoFocus}

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

• We should introduce a new prop shouldDelayFocus in BaseTextInput and when it is true we will use useFocusEffect for focusing on the input and we'll also set the autoFocus prop to false. The same approach is also used in SelectionList. By using this approach we can fix issues like these with a single prop.

    useFocusEffect(
        useCallback(() => {
            if (!shouldDelayFocus || !inputProps.autoFocus) {
                return;
            }

            requestAnimationFrame(() => {
                if (!input.current) {
                    return;
                }
                input.current.focus();
            });
        }, [shouldDelayFocus]),
    );

    autoFocus={shouldDelayFocus ? false : inputProps.autoFocus}

• Then we should pass shouldDelayFocus from SearchAutocompleteInput.
• Note: This won't effect SearchPageHeaderInput because we have already passed autoFocus={false} from that component.

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

N/A

What alternative solutions did you explore? (Optional)

Result

[Krishna2323]

PROPOSAL UPDATED