[Due for payment 2026-07-03] [Due for payment 2026-07-01] [$250] [Due for payment 2026-06-30] Expenses - All fields are unfocused after every input when tracking expense with FAB

[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: v9.4.17-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
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): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11/ Chrome
App Component: Money Requests

Action Performed:

1. Sign in to staging.new.expensify.com (Onboard with tracking expenses preffered)
2. Click on FAB > Create expense
3. In the "To" section Click and select personal space ( You )
4. Enter amount in the amount field/ Merchant field / Description

Expected Result:

All fields are focused until the user moves to another field

Actual Result:

All fields are un focuses after every input entered

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bandicam.2026-06-23.08-44-01-451.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7188120

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022069669942203062277
• Upwork Job ID: 2069669942203062277
• Last Price Increase: 2026-06-24
• Automatic offers:
• thelullabyy | Reviewer | 111813942

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/246477e481de983acc6f833d554b31f1f3b9d41930bf4ef3df0024db91ed84a4

[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]

Proposal

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

In the new inline manual-expense flow (FAB → Create expense → "personal space (You)"), the Amount / Merchant / Description inputs lose focus after every keystroke, so you can only type one character at a time.

What is the root cause of that problem?

The input is being programmatically blurred on every render — it is not a remount (runtime-verified: the <input> DOM node identity is preserved across keystrokes).

The chain:

1. The confirmation is rendered embedded inside IOURequestStartPage, which subscribes to the draft transaction via useOnyx(TRANSACTION_DRAFT…).
2. Each keystroke writes amount/merchant/comment to that draft → IOURequestStartPage re-renders.
3. It calls useResetIOUType(...), whose useFocusEffect callback is not wrapped in useCallback. React Navigation re-runs the callback on every render while focused (new callback identity each render).
4. On the global-create / self-DM path the draft transaction.reportID (set to UNREPORTED_REPORT_ID) ≠ route reportID, so the guard at L148-157 does not bail, and it reaches resetIOUTypeIfChanged(transactionRequestType).
5. resetIOUTypeIfChanged calls Keyboard.dismiss() unconditionally at L94-97 — before the iouRequestType === newIOUType early-return at L99. On web Keyboard.dismiss() blurs the focused input. No actual rebuild happens (the L99 guard returns) — only the stray Keyboard.dismiss() does the damage.

This is why it correlates with the personal-space / global-create case: when transaction.reportID === reportID (e.g. expense started from within a report), the L149 guard bails and the bug doesn't appear. It was surfaced by #94134 because that PR turned the embedded inline-input flow on by default.

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

Both of these, for defense in depth:

1. Stop firing Keyboard.dismiss() when nothing is reset. Move the Keyboard.dismiss() call in useResetIOUType.ts:94-97 to after the if (transaction?.iouRequestType === newIOUType) return; guard at L99. The keyboard then only dismisses when the IOU type genuinely changes (a tab switch), not on a no-op call.
2. Memoize the effect callback. Wrap the useFocusEffect callback at L140 in useCallback with a correct dependency array, so the whole effect body stops re-running on every render.

Investigation details & alternatives ruled out

• Verified at runtime (browser): the focused <input> DOM node is the same object before/after each keystroke — zero DOM mutations — so changing key, FlashList ListFooterComponent remounting, and the self-DM auto-assign loop are all ruled out. The blur is a programmatic input.blur() originating from Keyboard.dismiss().
• Per-keystroke draft writes originate from e.g. AmountField.tsx:221 and the Merchant/Description fields.
• The self-DM reportID = UNREPORTED_REPORT_ID assignment that makes the L149 guard false happens in IOURequestStepConfirmation.tsx:339-342.
• Strictly, the bug affects any global-create draft where transaction.reportID !== route.reportID; the personal-space "You" path is the most reproducible instance.

Confidence: high (static trace + runtime call-stack confirmation agree).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94273) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.