[Due for payment 2026-07-03] [Due for payment 2026-07-01] [Due for payment 2026-06-30] Android & iOS - Expense - Description field is not visible when focused

[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?: 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): 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. Open 1:1 DM with user.
3. Tap + > Create expense > Manual.
4. Tap Description field.

Expected Result:

Description field will be visible when focused.

Actual Result:

Description field is not visible when focused.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188124_1782174619506.Screen_Recording_20260623_082828_Expensify.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @aimane-chnaif

[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/2898d187600fe647513bf343ead480d087a3e9a13828475806301613a1145994

[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

Root Cause: PR #94134 ("remove isNewManualExpenseFlowEnabled beta flag") made the new inline manual‑expense flow the default for everyone. In that flow the Description field is now an inline TextInput rendered inside the confirmation list's FlashList footer (DescriptionField.tsx:88). The FlashList that renders it has no keyboard‑aware scrolling (BaseSelectionListWithSections.tsx:317-339 — keyboardShouldPersistTaps only, no automaticallyAdjustKeyboardInsets / scroll‑to‑focused‑input). On native, the ScreenWrapper KeyboardAvoidingView only shrinks the container; it never scrolls a focused footer input above the soft keyboard, so the focused Description field stays hidden behind it. Web/mWeb don't reproduce because the browser auto‑scrolls focused inputs into view.

Before the PR, the default (beta‑off) behavior rendered a navigate‑away MenuItemWithTopDescription that opened a separate full‑screen page, so the keyboard never overlapped an inline field — which is why this is "new feature, not in prod."

Recommended Fix: Add keyboard‑aware scroll‑into‑view to the confirmation list so the focused footer input scrolls above the keyboard on native. Practical options:

• Add automaticallyAdjustKeyboardInsets to the FlashList in BaseSelectionListWithSections.tsx:317 (helps iOS; verify Android), and/or
• Programmatically scrollToEnd/scroll-to-focused on the list when the Description (and Merchant) input focuses.

⚠️ Likely the same regression affects the Merchant field (MerchantField.tsx), which the same PR also flipped to an inline footer input — please verify and fix both.

Fastest mitigation (deploy blocker): Since this is a 1:1 revert of a beta‑flag removal, reverting #94134 restores the previous (navigate‑away) Description/Merchant fields and unblocks the deploy if a proper keyboard‑aware fix can't land quickly.

Investigation details & evidence

Render path (new flow):

1. + > Create expense > Manual → IOURequestStartPage.tsx renders the embedded IOURequestStepConfirmation (shouldHideHeader).
2. → its own ScreenWrapper (IOURequestStepConfirmation.tsx:716) → MoneyRequestConfirmationList.
3. → SelectionListWithSections (FlashList); the editable Description TextInput lives in the list's ListFooterComponent.
4. Tap Description → TextInput focuses → soft keyboard opens → footer input is not scrolled into view on native (BUG).

Why only native: KeyboardAvoidingView (via ScreenWrapper) only resizes the container. The FlashList has keyboardShouldPersistTaps="always" but no automaticallyAdjustKeyboardInsets and no scroll‑to‑focused‑input mechanism. On web the browser scrolls the focused input into view automatically, so it's not reproducible there.

PR #94134 diff confirms scope: The two start/confirmation files only had beta‑gate removals (e.g. shouldEnableKeyboardAvoidingView={isNewManualExpenseFlowEnabled} → shouldEnableKeyboardAvoidingView); DescriptionField.tsx flipped {isNewManualExpenseFlowEnabled && !isReadOnly ? → {!isReadOnly ?. No scroll wrapper was deliberately removed — the missing scroll‑into‑view is inherent to the inline‑footer design, simply made default by the PR.

Confidence: High — deterministic structural UI issue; root cause located with file:line evidence, no production logs needed.

---

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