Chat - Chat is scrolling up after editing a message

[vincdargento]

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.51-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-14589/folder/13176723/41237031/1295548358
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Web
App Component: Other

Action Performed:

1. Navigate to ND
2. Open a chat with some history
3. Send a message
4. Right click on the message
5. Click on "Edit Comment"
6. Edit the message and press ENTER

Expected Result:

Chat should maintain in the same position after editing a message.

Actual Result:

After editing a message chat is automatically scrolling up.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @Julesssss (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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #86119 - "decompose ReportScreen 5: self-subscribe List and Composer" by @adhorodyski (Medium confidence)
Related Issues: None found

Recommendation: NEEDS INVESTIGATION

The bug describes chat scrolling up after editing a message, which only reproduces on staging (not production). PR #86119 refactored ReportActionsView and ReportActionCompose components, making them self-subscribing and reducing prop drilling. This refactor could have inadvertently affected scroll position maintenance when messages are edited.

Rationale: While PR #86119 is the most likely candidate due to its timing (merged March 30) and scope (refactoring report view components), I cannot definitively confirm it touches message edit scroll behavior without deeper code analysis. The PR mentions it reduced ReportActionsView from 13 props to 2 and ReportActionCompose from 11 props to 1, which could affect how the component re-renders when a message is edited.

Labels: Keep DeployBlockerCash (this is a frontend bug affecting staging)

Detailed Analysis

Evidence

• Bug is staging-only, not reproducible in production
• Affects Windows Chrome (web platform)
• Version: 9.3.51-0
• The issue occurs specifically when editing a message and pressing ENTER
• Expected: Chat should maintain scroll position
• Actual: Chat automatically scrolls up

Candidate PRs Investigated

From the StagingDeployCash checklist for v9.3.51-0, I examined recent PRs that could affect chat/message behavior:

1. PR decompose ReportScreen 5: self-subscribe List and Composer #86119 (MOST LIKELY) - "decompose ReportScreen 5: self-subscribe List and Composer"

   • Merged: March 30, 2026
   • Major refactor of ReportActionsView and ReportActionCompose
   • Changed from prop-drilling architecture to self-subscribing components
   • Modified how report actions are rendered and updated
   • Could affect scroll position handling during message updates

2. PR [No QA] perf: remove redundant reportNameValuePairs collection subscription from LHN #86644 - LHN performance optimization (removed redundant NVP subscription)

   • Less likely: Affects sidebar, not report view

3. PR [NoQA] Removed unused files (batch 1) #86450, [No QA] fix: move AppStartTime recording from MainApplication to MainActivity #86468, [No QA] Add node_modules to module names #86515 - Various No QA changes

   • Unlikely: File cleanup, Android timing, module naming

Root Cause Hypothesis

The refactoring in PR #86119 changed how ReportActionsView manages its state and renders. When a message is edited, the component may be re-rendering or re-subscribing in a way that causes the scroll position to reset. The move from prop-based updates to useOnyx subscriptions could be triggering unnecessary list recalculations.

Next Steps

1. @adhorodyski - PR author should verify if scroll position preservation logic was maintained during the refactor
2. Check if ReportActionsList scroll position is being preserved when ReportActionsView updates
3. Verify if the message edit completion triggers a full list re-render instead of a targeted update
4. Test reverting PR decompose ReportScreen 5: self-subscribe List and Composer #86119 to confirm if it resolves the issue

[Julesssss]

@MelvinBot investigate this, try and locate the PR that caused this