[Due for payment 2026-07-01] [Due for payment 2026-06-30] After selecting report, keyboard closes after entering a number, report opens in background

[applause-bot]

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.4.17-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94134
Email or phone of affected tester (no customers): sdjnoisdjdosijsonssjo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Create two reports.
4. Open + > Create expense > Manual.
5. Tap Report field.
6. Tap another report.
7. Tap Amount field.
8. Enter two numbers.
   BUG 1: Keyboard closes after entering a number.
9. Tap app back button.
   BUG 2: App opens the report selected in Step 6 from confirm page.

Expected Result:

BUG 1: Keyboard will not close after entering a number.
BUG 2: App will remain in workspace chat after closing confirm page.

Actual Result:

BUG 1: Keyboard closes after entering a number.
BUG 2: App opens the report selected in Step 6 from confirm page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188090_1782171863116.Screen_Recording_20260623_074306_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7188090

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/2828301f7e29ae4b26aa5ace7bcd78f37701eada65af5d3b83b1871bb051ab6a

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #94134

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Issue Analysis

Both bugs were exposed by #94134, which removed the NEW_MANUAL_EXPENSE_FLOW beta and made the inline manual-expense confirmation (rendered on the start page) the default — which is why it reproduces in staging but not production (the beta was off there). Both root causes are pre-existing behaviors of the new flow that are now hit by everyone.

Problem

When creating a manual expense, after changing the Report via the inline Report field:

• BUG 1: the keyboard closes after typing the first digit in the inline Amount field.
• BUG 2: pressing Android back from the confirmation reveals the selected report instead of the workspace chat.

Root Cause

BUG 2 — report opens in background (high confidence):
The embedded confirmation runs a "pre-insert fullscreen under RHP" effect that optimistically mounts the post-submit destination report under the RHP so submit can just dismiss (IOURequestStepConfirmation.tsx:443-509). destinationReportID is derived from the live transaction reportID (:439-440). Selecting a different report inline calls setTransactionReport (useReportSelectionActions.ts:117-156), so destinationReportID flips to the newly-selected report and the effect re-fires, dispatching REPLACE_FULLSCREEN_UNDER_RHP — replacing the workspace-chat fullscreen with the selected report before any submit. PR #94134's Navigation.goBack(backTo) correctly pops the picker back to the confirmation; it simply surfaces this side effect when the user backs out.

BUG 1 — keyboard closes on first digit (medium confidence):
The inline Amount input (NumberWithSymbolForm) is the ListFooterComponent of a FlashList. The first keystroke flips isAmountSet false→true (MoneyRequest.ts:751-754), which changes shouldShowEmptyAmount/transactionAmount (AmountField.tsx:112-113) and re-renders the whole list. Because useConfirmationSections returns a brand-new sections array every render (no useMemo), useFlattenedSections hands FlashList new data, forcing it to re-render/recycle rows + footer and blurring the focused TextInput on Android. It's report-change-specific because after a report change the "To" section renders a real participant row (different flatListKey/item type) instead of the static empty-recipient row, so the first-keystroke re-render forces an actual row recycle.

Recommended Fix

Given this is a deploy blocker, the lowest-risk option is to revert #94134 (restore the beta gate) and fix forward. If fixing forward:

• BUG 2: Stop the pre-insert effect from swapping the underlying fullscreen when the inline Report field changes the destination. Restrict the report pre-insert to the genuine submit/dismiss path, or track the initial destinationReportID and bail if it changed due to an inline edit (or call Navigation.removePreInsertedFullscreenIfNeeded() when the report changes inline).
• BUG 1: Stabilize the list data — wrap the array built in useConfirmationSections in a useMemo keyed on its real inputs so the isAmountSet re-render no longer hands FlashList a new data array. (Do not "fix" it by re-focusing in the keystroke handler — that fights the symptom.)

Investigation details & evidence

BUG 2 data flow: Stack = [fullscreen: workspace chat] + [RHP: CREATE start page w/ embedded confirmation]. Tap Report field → push STEP_REPORT (backTo = start route, ReportField.tsx:125-130). Select report → setTransactionReport(reportID=selected) → goBack(backTo) pops to confirmation. transaction.reportID changed → destinationReportID flips → pre-insert re-fires → REPLACE_FULLSCREEN_UNDER_RHP(REPORT_WITH_ID(selected)) (Navigation.ts:1064-1106). Android back dismisses the RHP → revealed fullscreen is the selected report. Note: the PR change is in handleGlobalCreateReport (the global-create branch), not handleRegularReportSelection.

BUG 1 notes: The amount TextInput itself does not remount on the ''→value transition (NumberWithSymbolForm.tsx keeps an internal value state), so the blur originates from the parent FlashList re-render, not the input. Open question: whether memoizing sections alone fully fixes it or whether the inline (non-memoized) listFooterContent at MoneyRequestConfirmationList.tsx:501 also needs memoizing. An on-device repro would confirm.

Both root causes are in the Expensify/App repo (frontend) — no backend changes required.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR (fix-forward for both bugs).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's analysis.

[trjExpensify]

I can reproduce this reliably. CC: @thelullabyy

[m-natarajan]

Not repro on Samsung Galaxy A40/Android 11/App/Build v9.4.17-1 (Reverted)

mobizen_20260623_173342.mp4