[Due for payment 2026-05-26] Expense-Expense creation buttons are unresponsive on initial click

[mitarachim]

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.3.77-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: #89804
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 pro /Chrome
App Component: Chat Report View

Action Performed:

1. Navigate to staging.new.expensify.com
2. Create 2 WS and add expense in each WS chat
3. In LHN go to the other WS chat expense and click Submit

Expected Result:

The app should respond for the first tap of the button

Actual Result:

The app doesn't respond for the first tap of the button

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7157871_1779185733401.bandicam_2026-05-19_12-53-25-828.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @DylanDylann

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #90218 - "Drop FlashList hidden-render workaround using initial scroll index" by @VickyStash (High confidence)
Related Issues: #89768 (the issue #90218 was fixing)

Recommendation: REVERT

PR #90218 introduced a maintainVisibleContentPosition prop with autoscrollToBottomThreshold on the InvertedFlashList used in ReportActionsList. This prop is active during the initial render of money request/invoice reports (shouldAutoscrollToBottom = true), and React Native's autoscroll mechanism intercepts the first user touch event—preventing the Submit button (rendered inside the list) from responding on its first tap.

Assigned: @VickyStash (PR author), @DylanDylann, @Julesssss, @rlinoz (approving reviewers)
Labels: No label changes needed — DeployBlockerCash is correct for this frontend bug (staging-only, not in production).

Note: The melvin-bot assigned the issue to the reviewer of PR #89804 because that PR's QA test steps are what surfaced this bug. However, PR #89804 only changes search bulk pay logic (useSearchBulkActions.ts and Search.ts) and has no connection to the workspace chat Submit button. The actual causing PR is #90218.

📋 Detailed Analysis

Evidence

• The bug is reproducible on staging only (version 9.3.77-0), not production. This strongly indicates a regression introduced by a staging PR.
• PR Drop FlashList hidden-render workaround using initial scroll index #90218 is in the current StagingDeployCash and was merged on 2026-05-18, the same day as the report.
• PR Drop FlashList hidden-render workaround using initial scroll index #90218 refactored the entire ReportActionsList scroll initialization for money request and invoice reports (shouldBeAlignedToTop = isTransactionThreadReport || isMoneyRequestOrInvoiceReport).
• The new code introduces maintainVisibleContentPosition={{autoscrollToBottomThreshold: CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD, animateAutoScrollToBottom: false}} which is active when shouldAutoscrollToBottom is true.
• shouldAutoscrollToBottom initializes to shouldFocusToTopOnMount, which is true for workspace expense chat reports (money request reports).
• The autoscrollToBottomThreshold feature in React Native's ScrollView / FlashList is known to intercept the first touch event to determine if it should scroll, effectively swallowing the initial tap on interactive elements like the Submit button.
• The mechanism to disable this (setShouldAutoscrollToBottom(false) via requestAnimationFrame in onLoad) runs asynchronously and may not complete before a user taps immediately after navigation.

Verification

• Affected file: src/pages/inbox/report/ReportActionsList.tsx
• PR Drop FlashList hidden-render workaround using initial scroll index #90218 directly modifies ReportActionsList.tsx (confirmed via gh pr view 90218 --json files)
• The SubmitActionButton component is rendered inside the InvertedFlashList as part of the report action items, so it is subject to the maintainVisibleContentPosition touch interception
• PR feat: Always show pay sub menu to confirm the payment method in search bulk pay  #89804 only modifies src/hooks/useSearchBulkActions.ts and src/libs/actions/Search.ts — neither file is involved in the workspace chat report view or the Submit button

Root Cause

In ReportActionsList.tsx, when viewing a workspace expense report (money request report), shouldFocusToTopOnMount is true. This initializes shouldAutoscrollToBottom to true, which activates maintainVisibleContentPosition with autoscrollToBottomThreshold: 250. React Native's scroll view uses this threshold to intercept touch events on the first user interaction so it can auto-scroll if content is within 250 px of the bottom. This touch interception swallows the first tap on the Submit button. The flag is supposed to be cleared via requestAnimationFrame(() => setShouldAutoscrollToBottom(false)) in onLoad, but this async clearing can race with an immediate user tap, leaving shouldAutoscrollToBottom = true when the user first presses Submit.

The fix from PR #90218 also removed the previous StaticReportActionsPreview workaround and shouldScrollToEndAfterLayout mechanism, replacing them with the maintainVisibleContentPosition.autoscrollToBottomThreshold approach, which introduced this regression.