[$250] Android - Reports - Keyboard opens then closes quickly when tapping on search field

[nlemma]

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.2.13-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: #70082
Email or phone of affected tester (no customers): dsjionsjosdijdso@gmail.com
Issue reported by: Applause Internal Team
Device used: Samsung Galaxy Z Fold 4 / Android 15
App Component: Search

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Create an expense.
4. Go to Reports > Menu > Submit.
5. Expand the report view.
6. Tap on the search field.

Expected Result:

Keyboard will open.

Actual Result:

Keyboard opens then closes quickly when tapping on search field.

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

Bug6942375_1757657308274.Screen_Recording_20250912_140413_Expensify.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021968074105093937901
• Upwork Job ID: 1968074105093937901
• Last Price Increase: 2025-11-11
• Automatic offers:
• huult | Contributor | 109459141

Issue Owner

Current Issue Owner: @aldo-expensify

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (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 - Reports - Keyboard opens then closes quickly when tapping on search field

What is the root cause of that problem?

This bug only occurs on pages that have a footer, such as Search with the Submit or Approve type.

On Android, when the footer is rendered it changes the layout height and triggers a full re-layout. This causes the system to recalculate the screen with the keyboard open, which results in the TextInput losing focus. Without the footer, no layout shift happens and the input remains focused.

App/src/pages/Search/SearchPageNarrow.tsx

Lines 238 to 244 in aa03ded

	{shouldShowFooter && (
	<SearchPageFooter
	count={footerData.count}
	total={footerData.total}
	currency={footerData.currency}
	/>
	)}

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

We need to fix this bug by preventing layout recalculation. One way to do this is to hide the footer when SearchRouterList is open:

                {shouldShowFooter && !searchRouterListVisible && (
                    <View>
                        <SearchPageFooter
                            count={footerData.count}
                            total={footerData.total}
                            currency={footerData.currency}
                        />
                    </View>
                )}

I think this is the best solution, since we don't want to show footer on search router

Since the active search page on mobile devices (when the Search page is in focus) has its own display logic and is designed specifically for searching, there is no need to display the footer showing information from the currently active route. We also hide the list of results on the search page:

App/src/pages/Search/SearchPageNarrow.tsx

Lines 225 to 237 in aa03ded

	{!searchRouterListVisible && (
	<View style={[styles.flex1]}>
	<Search
	searchResults={searchResults}
	key={queryJSON.hash}
	queryJSON={queryJSON}
	onSearchListScroll={scrollHandler}
	contentContainerStyle={!isMobileSelectionModeEnabled ? styles.searchListContentContainerStyles : undefined}
	handleSearch={handleSearchAction}
	isMobileSelectionModeEnabled={isMobileSelectionModeEnabled}
	/>
	</View>
	)}

PS: we can do it only platoform specific if needed

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)

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.

[dmkt9]

Proposal

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

Keyboard opens then closes quickly when tapping on search field.

What is the root cause of that problem?

1. Initially, SearchPageHeader is rendered inside a View with position: absolute (styles.narrowSearchRouterInactiveStyle).
   

   App/src/pages/Search/SearchPageNarrow.tsx

   Line 178 in aa03ded

   <Animated.View style={[topBarAnimatedStyle, !searchRouterListVisible && styles.narrowSearchRouterInactiveStyle, styles.flex1, styles.bgTransparent]}>

2. When searchRouterListVisible === true, the absolute positioning is removed, and with flex: 1, the View tries to expand downward, causing a significant layout shift. If there are any components below this View, such as SearchPageFooter, the layout change can conflict with them, and the focused text input will immediately lose focus.

3. This results in the keyboard appearing and then disappearing right away.

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

It’s not sustainable to rely on remembering that no components (like SearchPageFooter) should be placed below this View. Therefore, the preferred solution is to avoid changing the position of the container View for SearchPageHeader (potentially applying this fix only on Android):

App/src/pages/Search/SearchPageNarrow.tsx

Line 178 in aa03ded

<Animated.View style={[topBarAnimatedStyle, !searchRouterListVisible && styles.narrowSearchRouterInactiveStyle, styles.flex1, styles.bgTransparent]}>

<Animated.View style={[topBarAnimatedStyle, styles.narrowSearchRouterInactiveStyle, styles.flex1, styles.bgTransparent]}>

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)

NA

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.

2025-09-12.23-40-14.mp4

[melvin-bot]

@JmillsExpensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

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

[melvin-bot]

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