[Due for payment 2026-07-08] [$250] Android - Expense - Unable to enter multi-line description

[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. Open FAB > Create expense > Manual.
4. Enter Amount.
5. Enter merchant.
6. Enter multi-line description.

Expected Result:

Multi-line description can be created.

Actual Result:

Multi-line description cannot be created. Done is shown on the keyboard instead of Enter.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188084_1782171411158.Screen_Recording_20260623_073609_Expensify.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070742408974490071
• Upwork Job ID: 2070742408974490071
• Last Price Increase: 2026-06-27
• Automatic offers:
• thelullabyy | Reviewer | 111844285

[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/b2bc21703b2ce63ea425589529dd00cb1236fe2df0a0f5d9b6faeba068aea86a

[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: The inline description input in the new manual expense flow hardcodes submitBehavior="blurAndSubmit" on a multi-line (autoGrowHeight) field. On Android native, blurAndSubmit forces the Enter key to act as Done (blur + submit) instead of inserting a newline, so a multi-line description can't be typed.

Before PR #94134, this inline TextInput was gated behind the isNewManualExpenseFlowEnabled beta — production users hit the else branch, which navigates to the dedicated IOURequestStepDescription page where the input sets no submitBehavior (RN defaults multi-line inputs to "newline"). The PR removed the beta gate, so everyone now uses the inline input with blurAndSubmit. This matches the report: reproducible in staging, not production (the beta was off in production).

Recommended Fix: In DescriptionField.tsx, remove submitBehavior="blurAndSubmit" (and the paired onSubmitEditing={onSubmitForm}) so the multi-line field falls back to the default "newline" behavior, allowing Enter to insert a line break — matching the dedicated step page. If submit-on-Enter must be preserved for single-line cases, gate the blurAndSubmit/onSubmitEditing props so they are not applied to this multi-line description input.

Investigation details

• The field is multi-line: it sets autoGrowHeight + maxAutoGrowHeight, and BaseTextInput treats autoGrowHeight as isMultiline (native impl).
• RN behavior: with multiline, the default submitBehavior is "newline"; explicitly passing "blurAndSubmit" overrides that and makes Enter submit/blur, surfacing Done on the Android keyboard — exactly the reported symptom.
• The dedicated IOURequestStepDescription input (used in the old/production path) passes no submitBehavior, so it keeps "newline" and accepts multi-line input. That's why production is unaffected.
• Alternative explanations considered & ruled out: not a returnKeyType/keyboardType issue (none set here), and not the keyboardSubmitBehavior form prop (that governs form dismissal, not the per-keypress newline-vs-submit decision). The single differing prop between the working step page and the broken inline field is submitBehavior.

---

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