Chat - chat is not scrolled to the bottom when sending a new comment while scrolled up

[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.32-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-54992/folder/13176722/41237006/1554722606?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome
App Component: Chat Report View

Action Performed:

1. Sign in to staging.new.expensify.com
2. Navigate to a conversation that has a long history (enough to scroll up or down/ create comments until history can be scrolled)
3. Scroll up to the first message (with the latest comment out of view)
4. Type a comment in the compose box and send

Expected Result:

Chat is scrolled to the bottom to view the latest comment

Actual Result:

Chat is not scrolled to the bottom when sending a new commnet

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203836_1783605556364.bandicam_2026-07-09_16-52-30-503.mp4

View all open jobs on GitHub

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

[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/6feda1c3eada94f83e4e02b4adae3a6e1147c6f57643bdfc8e644d6a3b8bc921

[melvin-bot]

Triggered auto assignment to @aldo-expensify (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #95045 - "Open linked message at top - 3" by @VickyStash (High confidence)
Related Issues: #92152 (the issue this PR was implementing), previously reverted as #94804

Recommendation: REVERT

This PR reworked the report list's scroll-to-bottom mechanism and made autoscrollToBottomThreshold conditional, so once shouldAutoscrollToBottom flips to false after mount FlashList no longer auto-scrolls to the newest comment. Given the size/risk of the rework (it was already reverted once as #94804 for multiple deploy blockers), a revert is safer than a same-day targeted patch.

Assigned: @VickyStash (PR author), @JS00001 (approving reviewer), @aimane-chnaif (approving reviewer)
Labels: No change. Only DeployBlockerCash is present (App deploy) and it should stay; no DeployBlocker (Web) label is present to remove.

📋 Detailed Analysis

Evidence

• The bug is reproducible on staging (v9.4.32) but not production, so it is a regression introduced by a PR in the current StagingDeployCash (Deploy Checklist: New Expensify 2026-07-09 #95677).
• Of all PRs in this deploy, only Open linked message at top - 3 #95045 touches the report scroll-positioning code. It modifies every relevant file: src/hooks/useReportActionsScroll.ts, src/pages/inbox/report/ReportActionsList.tsx, src/pages/inbox/report/useReportUnreadMessageScrollTracking.ts, src/components/FlashList/InvertedFlashList/index.tsx, and the @shopify/flash-list scroll patch. No other deploy PR touches maintainVisibleContentPosition, autoscrollToBottomThreshold, or the inverted list.
• The PR description states it "reworks how a report opens at a linked/unread message," replaces the old data-slicing approach, and that useReportActionsScroll "now owns mount positioning" and returns maintainVisibleContentPosition.
• Merge time 2026-07-09T07:05Z precedes the bug report 2026-07-09T14:25Z on the same day — timeline aligns.

Verification

• Affected behavior: auto-scroll to the newest comment on send, which is driven by FlashList's maintainVisibleContentPosition.autoscrollToBottomThreshold on the inverted report list.
• Confirmed Open linked message at top - 3 #95045 modifies this exact config. The diff changes it from an always-present value:
  autoscrollToBottomThreshold: shouldAutoscrollToBottom ? CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD : 0
  to a conditionally-spread object:
  ...(shouldAutoscrollToBottom ? {autoscrollToBottomThreshold: ..., animateAutoScrollToBottom: false} : {})
  and the new unit tests assert maintainVisibleContentPosition.autoscrollToBottomThreshold is undefined in the non-autoscroll state.

Root Cause

Previously the threshold key was always present (using 0 when not autoscrolling), which — per the code comment removed in this PR — is what let FlashList clear its internal pending-autoscroll flag and keep the list pinned to the newest message. After the rework, shouldAutoscrollToBottom is set to false shortly after mount via requestAnimationFrame(() => setShouldAutoscrollToBottom(false)), at which point autoscrollToBottomThreshold is omitted entirely from maintainVisibleContentPosition. With no threshold configured, sending a new comment while scrolled up no longer forces a scroll to the bottom, so the new comment stays out of view — matching the reported symptom.