Chat - "Latest messages" badge is not displayed while scrolling through chat history.

[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.54-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #97089
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Chat Report View

Action Performed:

Prerequisite: Chat doesn´t have unread messages.

1. Open the Expensify app.
2. Open any chat with long messages history or send messages until making chat scrollable.
3. Scroll up through chat history.
4. Note that "Latest Messages" grey badge is not visible.

Expected Result:

"Latest Messages" badge should appear on chat while scrolling up, away from the newest message, if there are no unread messages.

Actual Result:

"Latest Messages" badge is not visible on chat with long history while scrolling up when there are no unread messages.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7234039_1786758360161.Mig3.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022088519211887469525
• Upwork Job ID: 2088519211887469525
• Last Price Increase: 2026-08-15

Issue Owner

Current Issue Owner: @yusufdeveloper2903

[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/6040bb16cad7cef74ad8e9fbfc6582b76a7b7d886e0f2864973a436fb9904d71

[MelvinBot]

Issue Analysis

Root Cause (medium confidence — needs one runtime check to fully confirm): The grey "Latest messages" pill is always mounted; it's only slid in/out of view by a translateY animation gated on isActive. For a chat with no unread messages, the only thing that can turn isActive on is the scroll-offset check in updatePillVisibility: currentVerticalScrollingOffsetRef.current > 2000. That offset is fed the inverted list's raw event.nativeEvent.contentOffset.y, which under the FlashList v2 inverted model doesn't appear to grow to the 2000 threshold on scroll-up — so the pill never activates.

Notably, the non-inverted sibling list computes a normalized distance-from-bottom for the exact same threshold (MoneyRequestReportActionsList.tsx:476-483: fullContentHeight - layoutMeasurement.height - contentOffset.y), while the inverted chat list uses the raw offset. That asymmetry is the prime suspect.

This is not caused by the PR it was found under (#97089). That PR only swapped Button → ButtonComposed in FloatingMessageCounter.tsx (success→variant); it doesn't touch mounting, isActive, the animation, or hasNewMessages, and the neutral pill still renders a visible grey background. Consistent with the report's "reproducible in production: Yes", this looks like a latent regression from the InvertedFlashList v2 migration, not the button migration.

Recommended Fix: Make the inverted path compare a true distance-scrolled-up-from-bottom against the threshold instead of the raw contentOffset.y — i.e. mirror what MoneyRequestReportActionsList already does — in useReportActionsScroll.ts:217. Confirm first with a one-line runtime check (log contentOffset.y while scrolling up a long, no-unread chat and see whether it ever exceeds 2000).

Investigation details & evidence

How the pill is wired

• ReportActionsList.tsx:448-450 renders <FloatingMessageCounter> unconditionally with hasNewMessages={!!unreadMarkerReportActionID} (→ false, so the grey "Latest messages" copy is the intended render) and isActive={isFloatingMessageCounterVisible}.
• FloatingMessageCounter.tsx:129-135 shows/hides via a translateY spring (inactive -40 → active +10). The button is always in the tree, so it's hidden by transform, not unmounted. (A verify-only web check confirmed a "Latest messages" node present in the DOM but not visually rendered at rest.)

Why the no-unread case has a single point of failure

• updatePillVisibility sets isFloatingMessageCounterVisible = true only when offset > 2000 && !hasUnreadMarkerReportAction && !shouldBeAlignedToTop.
• The other setter, onViewableItemsChanged, is guarded by hasUnreadMarkerReportAction, so it never fires for a no-unread chat. → The grey pill depends 100% on contentOffset.y > 2000.
• Threshold: CONST.REPORT.ACTIONS.LATEST_MESSAGES_PILL_SCROLL_OFFSET_THRESHOLD = 2000 — unchanged for months, so the constant itself isn't a fresh regression.
• shouldBeAlignedToTop (transaction/money-request/invoice reports only) and shouldDisablePillTracking (!!initialScrollKey) are both false for a normal no-deep-link chat, so neither suppresses the pill here.

Ruled out

• variant={undefined} making the button transparent — disproven; ButtonComposed always applies styles.button (opaque theme.buttonDefaultBG) + the SMALL size style, identical background to the old Button for success={false}.
• PR Migrate Button to ButtonComposed (batch 8) #97089 mounting/animation changes — none exist in that diff.

Still needs runtime confirmation: whether the inverted FlashList's contentOffset.y actually fails to cross 2000 (right sign/scale) on scroll-up. This is a client scroll behavior, not visible in backend logs — best gathered via device/browser instrumentation.

Possibly related: #93104 touches the same FloatingMessageCounter component, but for the green "New messages" (unread) pill — a different code path, not a duplicate.

---

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

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022088519211887469525

[melvin-bot]

@ZhenjaHorbach Whoops! This issue is 2 days overdue. Let's get this updated quick!

[oqildev]

@ZhenjaHorbach

I can't reproduce this. The pill is gated on
LATEST_MESSAGES_PILL_SCROLL_OFFSET_THRESHOLD = 2000,
and the chat in the video (~31 one-line messages) has only ~600px of scrollable range, so the threshold is
never reached. I logged contentOffset.y locally in a longer chat and the pill appears and works correctly
as soon as it passes 2000.

One correction on Melvin's proposal: FlashList v2 inverts with a CSS transform only (scaleY:-1 on iOS/web,
rotate:180deg on Android) and forwards the raw scroll event, so contentOffset.y is already the distance
scrolled up from the newest message. MoneyRequestReportActionsList normalizes it only because that list is
isInverted: false, and copying that math into the inverted chat list would flip the pill, showing it at the
bottom and hiding it when you scroll up.

I'd close this as working as designed. If 2000px is considered too far in practice, lowering the constant is
the only real change, and that's a design call rather than a bug fix.

Repro video:

Latest.message.mp4

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

In a chat with no unread messages, the grey "Latest messages" pill has exactly one trigger: a raw scroll-offset comparison against LATEST_MESSAGES_PILL_SCROLL_OFFSET_THRESHOLD, which is 2000.

App/src/pages/inbox/report/useReportUnreadMessageScrollTracking.ts

Lines 92 to 100 in 0886cd3

	// display floating button if we're scrolled more than the offset
	if (
	currentVerticalScrollingOffsetRef.current > CONST.REPORT.ACTIONS.LATEST_MESSAGES_PILL_SCROLL_OFFSET_THRESHOLD &&
	!isFloatingMessageCounterVisible &&
	!hasUnreadMarkerReportAction &&
	!shouldBeAlignedToTop
	) {
	setIsFloatingMessageCounterVisible(true);
	}

The hook's other setter, onViewableItemsChanged, is gated on hasUnreadMarkerReportAction, so it never runs for a read chat:

App/src/pages/inbox/report/useReportUnreadMessageScrollTracking.ts

Lines 148 to 155 in 0886cd3

	// display floating button if the unread report action is out of view
	if (!unreadActionVisible && hasUnreadMarkerReportAction) {
	setIsFloatingMessageCounterVisible(true);
	}
	// hide floating button if the unread report action becomes visible
	if (unreadActionVisible && hasUnreadMarkerReportAction) {
	setIsFloatingMessageCounterVisible(false);
	}

App/src/CONST/index.ts

Line 1854 in 0886cd3

LATEST_MESSAGES_PILL_SCROLL_OFFSET_THRESHOLD: 2000,

So the no-unread pill depends 100% on contentOffset.y > 2000. The problem is that 2000 is a raw pixel count, and a chat's entire scroll range is usually far below it — the reporter's chat measured ~600px end to end. contentOffset.y can never reach 2000, so the branch never fires and the pill never appears, no matter how far you scroll. I confirmed this on web too, in the video above: a ~1370px read chat scrolled all the way up peaks at ~800px of offset and the pill stays hidden; I first laid this mechanism out in my earlier comment.

The deeper point is that a pixel constant is the wrong kind of signal here. Before a12c2b5b022 (PR #66683) this pill was driven by IS_CLOSE_TO_NEWEST_THRESHOLD = 15 — a semantic "more than 15 actions away from the newest" check, not a pixel count. That commit deleted the semantic check and replaced it with the 2000 pixel threshold, tuned for that PR's own deep-link-return scenario. The pill was always meant to mean "away from the newest message" (which is exactly what the Expected Result asks for); the pixel constant is what broke that intent. Replacing one magic pixel number with another leaves the same fragility — it still depends on device size, font scale, and message density.

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

Drive the no-unread pill off the visibility of the newest action — a device-independent signal the hook already receives in onViewableItemsChanged. In an inverted list the newest action is index 0, so the pill should be visible exactly when index 0 is out of view. This is the same viewability mechanism the green "New messages" pill already uses for the unread marker.

Inside onViewableItemsChanged, after viewableIndexes is computed:

// Inverted read chat (no unread marker): show the "Latest messages" pill exactly when the newest
// action (index 0 in the inverted list) scrolls out of view. This keys off viewability, already
// delivered here, instead of a raw contentOffset.y pixel threshold that most chats never reach.
// shouldDisablePillTracking suppresses this during initial linked-message positioning; onLoad then
// refreshes the pill via updatePillVisibility once positioning settles.
if (isInverted && !hasUnreadMarkerReportAction && !ref.current.shouldBeAlignedToTop && !ref.current.shouldDisablePillTracking) {
    const isNewestActionVisible = viewableIndexes.includes(0) && !ref.current.hasNewerActions;
    setIsFloatingMessageCounterVisible(!isNewestActionVisible);
}

And in updatePillVisibility, recompute the inverted case from the last viewable items instead of the pixel branch, so onLoad's post-positioning refresh still works:

if (isInverted && !hasUnreadMarkerReportAction) {
    if (shouldBeAlignedToTop) {
        return;
    }
    const viewableIndexes = ref.current.previousViewableItems.map((viewableItem) => viewableItem.index).filter((value) => typeof value === 'number');
    if (viewableIndexes.length === 0) {
        return;
    }
    const isNewestActionVisible = viewableIndexes.includes(0) && !hasNewerActions;
    setIsFloatingMessageCounterVisible(!isNewestActionVisible);
    return;
}

onViewableItemsChanged is memoized with an empty dependency array, so shouldBeAlignedToTop, shouldDisablePillTracking and hasNewerActions are read from the existing ref, kept in sync by a small effect — the same pattern already used for reportID and onUnreadActionVisible. The non-inverted MoneyRequestReportActionsList path keeps its existing pixel behavior (the new branch is gated on isInverted), so its blast radius is zero.

This design handles the three concerns the viewability approach usually raises:

• onLoad / deep-link refresh. I do not suppress updatePillVisibility for the inverted list — I make it recompute from viewability. onLoad still calls updatePillVisibility() after linked-message positioning settles, and it now refreshes the pill from the settled viewable items. shouldDisablePillTracking still suppresses tracking during the initial positioning itself.

  App/src/hooks/useReportActionsScroll.ts

  Lines 375 to 391 in 0886cd3

  	const onLoad = () => {
  	if (shouldDisablePillTracking) {
  	// Wait one frame so the initial positioning can settle, then disable it.
  	requestAnimationFrame(() => {
  	setShouldDisablePillTracking(false);
  	updatePillVisibility();
  	});
  	}
  	if (!shouldFocusToTopOnMount) {
  	return;
  	}
  	if (!reportLoadingState?.hasOnceLoadedReportActions && !isOffline) {
  	return;
  	}
  	// Wait one frame so the initial autoscroll-to-top can settle, then disable it.
  	requestAnimationFrame(() => setShouldAutoscrollToBottom(false));
  	};

• A streamed draft at index 0. Index 0 is by construction the bottom-most rendered row — the newest content on screen — whether it is a real action or a spliced concierge draft. "Index 0 out of view" therefore always means "the newest content is off screen", and the pill's tap target (scrollToBottomAndMarkReportAsRead) scrolls to that same row. A draft splicing in or out only ever occupies that same bottom slot, so it does not flip the pill.

  App/src/pages/inbox/report/ReportActionsList.tsx

  Lines 204 to 235 in 0886cd3

  	const renderedVisibleReportActions = (() => {
  	if (!draftReportAction) {
  	return sortedVisibleReportActions;
  	}
  	if (showHiddenHistory && sessionStartTime && draftReportAction.created < sessionStartTime) {
  	return sortedVisibleReportActions;
  	}
  	// Insert the synthetic draft into the already-descending render list without treating it as a persisted report action.
  	for (const [index, action] of sortedVisibleReportActions.entries()) {
  	if (action.reportActionID === draftReportAction.reportActionID) {
  	const isDraftStillRevealingPersistedAction = getReportActionHtml(action) !== getReportActionHtml(draftReportAction);
  	if (!isDraftPendingCompletion && !isDraftStillRevealingPersistedAction) {
  	return sortedVisibleReportActions;
  	}
  	const visibleReportActionsWithDraft = [...sortedVisibleReportActions];
  	visibleReportActionsWithDraft[index] = draftReportAction;
  	return visibleReportActionsWithDraft;
  	}
  	if (isNewerReportAction(draftReportAction, action)) {
  	const visibleReportActionsWithDraft = [...sortedVisibleReportActions];
  	visibleReportActionsWithDraft.splice(index, 0, draftReportAction);
  	return visibleReportActionsWithDraft;
  	}
  	}
  	const visibleReportActionsWithDraft = [...sortedVisibleReportActions];
  	visibleReportActionsWithDraft.push(draftReportAction);
  	return visibleReportActionsWithDraft;
  	})();

• Newer actions still unloaded. When hasNewerActions is true, index 0 of the loaded window is not the true newest action, so isNewestActionVisible stays false and the pill remains shown — mirroring the existing !hasNewerActions guard.

Regression safety: unread chats are untouched (both new branches are gated on !hasUnreadMarkerReportAction, the green pill is still driven by the marker's viewability); aligned-to-top reports are untouched (!shouldBeAlignedToTop still blocks the pill); a fresh mount at the bottom keeps the pill hidden because index 0 is viewable.

Automated tests (tests/unit/useReportUnreadMessageScrollTrackingTest.ts):

1. Read inverted chat, offset 600, newest action (index 0) scrolled out of view → pill visible. This is the bug: red on main with Expected: true, Received: false, green with the fix.
2. Same chat, index 0 back in view → pill hidden.
3. hasNewerActions true while index 0 is visible → pill stays shown.
4. shouldBeAlignedToTop report → pill never shows even with index 0 out of view.

I implemented this on a branch and ran it — working diff here: dilshodmackbook-sketch/App@main...dilshodmackbook-sketch:App:fix/98708-latest-messages-pill-viewability

The three behavior tests fail on main and all pass with the fix (17 in this file, including the existing 13), and FloatingMessageCounterTest, ReportActionsListContextTest and ReportActionsListThresholdTest stay green. typecheck, eslint and the React Compiler compliance check all pass. I have verified the hook under Jest and reproduced the before/after in the browser; I have not run it on an Android device.

What alternative solutions did you explore? (Optional)

Lower the pixel threshold from 2000 to 250 (ACTION_VISIBLE_THRESHOLD). This does make the reporter's chat show the pill, and it is the smallest possible diff. I did not choose it because it keeps a magic pixel number — the same class of signal that caused this bug — so the trigger still depends on device size and font scale, and 250 is itself arbitrary between chats. It also changes the shared threshold for the non-inverted MoneyRequestReportActionsList, widening the behavior change beyond the reported screen. Viewability removes the magic number entirely and restores the pre-#66683 "away from the newest" intent.

Make the threshold viewport-relative (one layoutMeasurement.height). It reads more principled than a fixed pixel, but one viewport on a phone is roughly 640–680px, which still exceeds the reporter's ~600px total range — so the pill would still never appear for the reported chat.

Close as working-as-designed. The 2000 branch does fire in a long enough history, so the code behaves as written. It loses on the Expected Result, which explicitly asks for the pill "while scrolling up, away from the newest message" — a state most read chats reach long before 2000px.

[melvin-bot]

@ZhenjaHorbach Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

@ZhenjaHorbach Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!