Android - Expense - App scrolls down to mid report view when text report field is focused

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

Version Number: 9.5.8-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: #102142
Email or phone of affected tester (no customers): jsoidjndoiniodnsjojd@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:

Precondition:

Enable Report fields.
Create a text report field.

Launch Expensify app.
Go to workspace chat.
Create an expense.
Open the report.
Tap on the text report field.

Expected Result:

App will not scroll down when text report field is focused.

Actual Result:

App scrolls down to mid report view when text report field is focused.
On iOS app, it scrolls down then scrolls back to text report field when text report field is focused.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7285338_1791899664313.Screen_Recording_20261013_215228_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7285338

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

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

@AndrewGable

@AndrewGable you have been assigned to this deploy blocker because you reviewed the offending PR: #102142

👋 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:

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

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

Deploy Blocker Investigation

Causing PR (high confidence): Restore: Show up to three report fields per row and edit them inline, merged by AndrewGable on 2026-10-12.

Recommendation: roll forward. Revert if no fix lands before the deploy. In MoneyReportView, render report fields on one-expense reports as rows that open the editor page again, as they were before the PR. Keep inline editing only in the multi-expense table view. A revert should be clean as a fallback, but it would be the second revert of this feature.

Why: the PR made report fields on one-expense reports inline TextInputs inside the inverted report feed. When the Android keyboard opens, the window shrinks and the list scrolls away from the field. This bug was already reported against the original PR in Android - Expense - Report auto scrolls to bottom after opening report field. The restore PR knowingly deferred it to Android - Report auto scrolls to bottom when the keyboard opens for an input inside the report, which is still open.

Investigation details

Permalinks are at App 0714dac08359d32143b16eabeb16629944717845.

How the fields end up in the inverted list

shouldDisplayReportTableView returns false for one-expense reports. As a result, ReportActions.tsx renders ReportActionsList.
ReportActionsList is an InvertedFlashList.
The report's first action renders MoneyReportContentCreated, which renders MoneyReportView.
The PR added MoneyRequestViewReportFields to MoneyReportView.tsx:162-174. This replaced the rows that opened the editor page.
Each field is a ReportFieldInlineInput, a new file in this PR. For text fields, it renders a real TextInput.

Scroll mechanism (from code analysis, not confirmed on a device)

One-expense reports open scrolled to the top. In that mode, useReportActionsScroll.ts:210-221 keeps autoscrollToBottomThreshold at 0.
On a short report, FlashList treats the view as near the bottom, so it scrolls to the bottom on every layout change.
The Android keyboard resizes the window, which triggers the scroll. On iOS, the native scroll-to-focused-input then brings the field back. That matches the "scrolls down then back" report.
This never happened before because the composer sits outside the list. Report fields are the first input most users focus inside it.

Other checklist PRs ruled out

Fix elements hidden behind keyboard in landscape mode only takes effect in landscape.
Collapse consecutive system messages in report audit trails only changes how messages are grouped.

Proper fix: move the fields out of the inverted list, or stop FlashList autoscroll when the keyboard resizes the window. That work is tracked in the open follow-up issue.

I did not test on a device. The bug only happens in the native apps, and this run could only test web.

Suggested AI code review rule

The same bug has now shipped twice, and a grep can catch it.

Rule: UI-6: Don't put keyboard-opening inputs inside the inverted report feed.
Condition: flag a TextInput, DatePicker, FormProvider, or other keyboard-opening control rendered by a report action in ReportActionsList. This covers src/components/ReportActionItem/**, src/pages/inbox/report/*ContentCreated*, and the components they render.
Fix: edit the value on a separate page, in the right-hand panel, or in a popover.
Search: grep -rln "TextInput\|DatePicker\|FormProvider" src/components/ReportActionItem src/pages/inbox/report
Location: App/.claude/skills/app-coding-standards/rules/, with an index entry under UI in SKILL.md.

view run

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.