IOU - Report page is blank when add second expense on scrolled chat

[applause-bot]

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

---

Version Number: 9.4.69-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
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/72092551/folder/53758047/41237826/1720579507?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocemate+buzz1974@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iphone 11/26.2
App Component: Chat Report View

Action Performed:

1. Go to FAB> Create expense> Finish the IOU flow
2. Send a lot of messages so the page is scrollable
3. Scroll a moderate amount of the conversation history
4. On the compose box tap the + button> Create expense> Finish the IOU flow

Expected Result:

Page should scroll to the Reports

Actual Result:

Page becomes blank

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7250125_1788441688248.ScreenRecording_09-03-2026_15-03-42_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7250125

Issue Owner

Current Issue Owner: @mananjadhav

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

[MelvinBot]

Proposal

What is the root cause of that problem?

When the second expense is added to a chat, the app scrolls the list to an index far outside the rendered window, and the inverted FlashList ends up parked at an offset where nothing is materialized — a blank viewport.

The fork is in useReportActionsNewActionLiveTail.ts:129-147:

const index = sortedVisibleReportActions.findIndex((item) => item.reportActionID === action?.reportActionID);
if (action?.actionName === CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW) {
    if (index > 0) {
        setTimeout(() => { reportScrollManager.scrollToIndex(index); }, 100);
    } else {
        setIsFloatingMessageCounterVisible(false);
        reportScrollManager.scrollToBottom();
    }
    ...
}
setIsScrollToBottomEnabled(true);   // armed even on the scrollToIndex path

Two things make expense #2 different from expense #1:

1. The report-preview action is reused, not re-created. For the second expense the open expense report still accepts transactions, so MoneyRequestBuilder.ts:1635 reuses the existing preview and merges it in place via updateReportPreview, which changes neither reportActionID nor created. The preview therefore stays buried under all the messages sent in step 2, so index is large instead of 0.
2. The list is scrolled up, which is also what enables maintainVisibleContentPosition (useReportActionsScroll.ts:209-219 — it's gated on hasScrolledOverThreshold).

FlashList v2 takes no estimatedItemSize; a jump to a distant, never-measured index is computed from running-average heights and clamped only against the estimated content height. Chat rows vary wildly in height, so the resulting offset can land past the real content end. On iOS a programmatic setContentOffset: is not clamped to content bounds. The team has already hit this exact failure mode — see the comment at MoneyRequestReportActionsList.tsx:588-591 ("scrollToEnd targets an estimated content-end offset that leaves the bottom blank on large transaction+chat lists").

Making it worse, setIsScrollToBottomEnabled(true) on line 147 is outside the if/else, so the scrollToIndex path also arms a scrollToBottom() that fires on the list's next layout (ReportActionsList.tsx:481-484 → flushPendingScrollToBottom) — two overlapping scroll state machines while MVCP offset correction is suspended.

Note the expected result in the report, "Page should scroll to the Reports", is exactly what the index > 0 branch intends. The intent is right; the execution strands the scroll offset.

What changes do you think we should make in order to solve the problem?

In useReportActionsNewActionLiveTail.ts:

1. Move setIsScrollToBottomEnabled(true) (line 147) into the branches that actually want a bottom scroll, so the scrollToIndex path stops arming a competing flushPendingScrollToBottom().
2. Make the jump safe. Either pass viewPosition so FlashList anchors the target row in the viewport instead of landing on a bare offset, or gate the scrollToIndex on the target being within/near the rendered window and fall back to scrollToBottom() otherwise. A follow-up offset check after measurement settles (re-clamping against the real contentSize.height) would make it robust for very long histories.

What alternative solutions did you explore? (Optional)

Ruled out and residual uncertainty

Ruled out:

• Empty data array. If sortedVisibleReportActions went empty, shouldShowDerivedTimingSkeleton would render a skeleton, not a blank page.
• Screen remount / re-keyed list. The RHP dismissal degrades to a plain dismissModal() because the report is already topmost (Navigation.ts:952-957), so listID is stable and the FlashList is not re-keyed.
• openReport refiring / page pruning. The live-tail jump that would prune pages is explicitly skipped for REPORT_PREVIEW actions (line 111-112).
• Item count / key churn. keyExtractor is reportActionID, and the reused preview keeps its ID and created, so nothing reorders.

Not verified — needs an on-device iOS repro. This is a client-side scroll race with no server-side trace, so there is no log evidence to confirm it. I could not distinguish which native step actually strands the offset (unclamped setContentOffset:, a content-height collapse after real measurement, or an MVCP scrollBy with a stale anchor); all three land in the same place. Instrumenting the index passed to scrollToIndex, plus contentOffset.y versus the real contentSize.height right after the jump, would settle it.

Platform scope. Only iOS is checked on the report. Android runs the same useReportScrollManager/index.native.ts code path and may differ only because its inverted path takes a clamped scrollTo fallback — worth re-testing on Android before assuming it is iOS-only. On web, DOM scrollTop clamps, which fits the non-repro there.

Regressing PR. Not pinned. git blame on the branch points at #94474, but that PR is an InteractionManager migration that only rewrapped the surrounding lines, and the file moved from src/pages/home/report/ to src/pages/inbox/report/, so blame is obscured.

Possibly related (not duplicates): #99559 (chat not autoscrolled to bottom after sending messages, web) and #92420 (blank WS chat after tapping the floating pill) touch the same scroll-after-new-action machinery.

---

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

---

view run · view recording

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[mukhrr]

cannot reproduce

[annaweber830]

I can reproduce

[mananjadhav]

Reviewing.

[danielamodu]

Proposal

Please re-state the problem that we are trying to solve in this issue.

In a chat with existing message history that is scrolled up, adding a second expense to an existing report results in the chat/report view rendering as a blank screen when returning to it.

What is the root cause of that problem?

In src/pages/inbox/report/useReportActionsNewActionLiveTail.ts (lines 129-148):

const index = sortedVisibleReportActions.findIndex((item) => item.reportActionID === action?.reportActionID);
if (action?.actionName === CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW) {
    if (index > 0) {
        setTimeout(() => {
            reportScrollManager.scrollToIndex(index);
        }, 100);
    } else {
        setIsFloatingMessageCounterVisible(false);
        reportScrollManager.scrollToBottom();
    }
    if (action?.reportActionID) {
        setActionIdToHighlight(action.reportActionID);
    }
} else {
    setIsFloatingMessageCounterVisible(false);
    reportScrollManager.scrollToBottom();
}

setIsScrollToBottomEnabled(true);

There are two combined root causes:

1. Unconditional setIsScrollToBottomEnabled(true):
   setIsScrollToBottomEnabled(true) is placed unconditionally at line 147 outside the if/else block. Even when index > 0 executes scrollToIndex(index), setIsScrollToBottomEnabled(true) arms a flushPendingScrollToBottom() trigger in ReportActionsList. On the next layout pass, scrollToBottom() fires immediately after scrollToIndex(index), causing two competing scroll commands to fight each other.
2. Unclamped/Unmeasured scrollToIndex in FlashList:
   When a second expense is added to an existing report, the backend reuses the existing REPORT_PREVIEW action (MoneyRequestBuilder.ts and updateReportPreview). The preview action retains its original reportActionID and timestamp. In a chat with messages sent afterwards, index is deep in the list (e.g. index 25+). When scrollToIndex(index) runs on an inverted FlashList before that distant item has been laid out and measured in the current window, FlashList computes an offset from unmeasured estimates that can overshoot the actual content bounds. With offset maintenance suspended, FlashList parks the scroll container at an offset where no items are materialized, rendering a blank white page.

What changes do you think we should make in order to solve the problem?

In src/pages/inbox/report/useReportActionsNewActionLiveTail.ts:

1. Move setIsScrollToBottomEnabled(true) inside the bottom-scroll branches:
   Only enable isScrollToBottomEnabled(true) when genuinely scrolling to the bottom (line 137 and line 144). Do not arm flushPendingScrollToBottom() when scrollToIndex is triggered.

2. Anchor the scroll with viewPosition and validate bounds:
   Pass {viewPosition: 0.5} to reportScrollManager.scrollToIndex so FlashList anchors the target row smoothly in the visible viewport. If index is not found (index === -1), fall back to scrollToBottom().

const index = sortedVisibleReportActions.findIndex((item) => item.reportActionID === action?.reportActionID);
if (action?.actionName === CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW) {
    if (index > 0) {
        setTimeout(() => {
            reportScrollManager.scrollToIndex(index, true, {viewPosition: 0.5});
        }, 100);
    } else {
        setIsFloatingMessageCounterVisible(false);
        reportScrollManager.scrollToBottom();
        setIsScrollToBottomEnabled(true);
    }
    if (action?.reportActionID) {
        setActionIdToHighlight(action.reportActionID);
    }
} else {
    setIsFloatingMessageCounterVisible(false);
    reportScrollManager.scrollToBottom();
    setIsScrollToBottomEnabled(true);
}

3. Automated Testing:
   Add unit test in tests/unit/useReportActionsNewActionLiveTailTest.ts:
   • Verify that when a REPORT_PREVIEW action has index > 0, scrollToIndex is called with the action index and isScrollToBottomEnabled remains false.
   • Verify that when a REPORT_PREVIEW action has index <= 0 or any other action type arrives, scrollToBottom is called and isScrollToBottomEnabled is set to true.

What alternative solutions did you explore? (Optional)

• Always calling scrollToBottom() on expense creation:
  Rejected because when a user adds an expense to an existing report that is located higher in the chat, scrolling them all the way to the bottom away from the expense preview they just modified is confusing and contradicts the intended UX. Anchoring to the preview with viewPosition: 0.5 while disabling the conflicting bottom flush preserves the intended behavior without stranding the scroll offset.

[melvin-bot]

@mananjadhav Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!