[HOLD #92152][$250] No "New messages" pill when returning to a chat with multiple unread messages — only the first unread is shown

[melvin-bot]

Problem

When returning to a room or DM that has multiple unread messages, the chat positions you at the "New" unread marker but shows only the first unread message. No ↓ New messages floating pill appears, so there is no indication that more messages exist below the fold. The same issue occurs when multiple messages arrive rapidly while you are already in the chat.

Reproducible consistently in rooms (e.g. #social) and DMs.

Repro steps

Scenario A – returning to a chat after being away

1. Be active in a room or DM and send or read a message (so you have a "last read" position).
2. Leave the chat / go offline for a period while other people post multiple messages.
3. Return to the chat.
4. Expected: The chat opens at the "New" marker AND a ↓ New messages pill appears indicating more messages exist below.
5. Actual: The chat opens at the "New" marker showing only the first unread message. No pill appears. All subsequent messages are hidden below the fold with no indication they exist.

Scenario B – multiple messages arrive while you are in the chat

1. Be in a DM or room with another person.
2. Have the other person send 5+ messages in quick succession.
3. Expected: Either auto-scroll to the newest message, OR show the ↓ New messages pill.
4. Actual: View stays put, only the most recent message (nearest the unread marker) is visible, no pill appears.

Root cause analysis

There are two related mechanisms at play:

1. Auto-scroll intentionally skips the recipient

useReportActionsNewActionLiveTail.ts only auto-scrolls to the bottom for messages sent by the current user (isFromCurrentUser). For incoming messages the recipient is expected to rely on the floating pill — which is where the bug lies.

2. The pill is gated on the unread marker's visibility, not the bottom's

In useReportUnreadMessageScrollTracking.ts, the pill is force-hidden whenever the unread marker row is considered visible:

const unreadActionVisible = isInverted ? unreadActionIndex >= minIndex : unreadActionIndex <= maxIndex;

if (unreadActionVisible && hasUnreadMarkerReportAction) {
    setIsFloatingMessageCounterVisible(false);
}

The implicit assumption is "if you can see the New marker, you can see all the new messages." This only holds when the entire unread block fits in one viewport.

When many messages have accumulated, ReportActionsList.tsx positions the list at the unread marker (via initialScrollKey), which places the marker near the top of the visible area. The marker row is technically visible so the pill is suppressed — but all the newer messages below the marker are off-screen with no way to know they exist.

Suggested fix direction: Gate the pill on whether the newest / bottom action is visible (combined with "has unread"), rather than solely on whether the unread marker is visible. This way, landing at the marker with more messages below the fold will still surface the ↓ New messages pill.

Affected areas

• src/pages/inbox/report/useReportUnreadMessageScrollTracking.ts
• src/pages/inbox/report/useReportActionsNewActionLiveTail.ts
• src/components/ReportActionsList.tsx (initialScrollKey / scroll-on-mount logic)

Platform

All platforms (confirmed on web/desktop NewDot)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064416459333148814
• Upwork Job ID: 2064416459333148814
• Last Price Increase: 2026-06-16

Issue Owner

Current Issue Owner: @mkhutornyi

[MelvinBot]

Proposal

What is the root cause of that problem?

The ↓ New messages pill is suppressed whenever the unread marker row is in the viewport — but the marker can be visible while the new messages below it are off-screen.

When you return to a chat with unread messages, the list mounts positioned at the unread marker via initialScrollKey (ReportActionsList.tsx:252-263). This places the marker near the top of the visible area, with the newer messages below the fold.

The pill visibility logic in useReportUnreadMessageScrollTracking.ts:128-137 then force-hides the pill because the marker row is technically visible:

const unreadActionVisible = isInverted ? unreadActionIndex >= minIndex : unreadActionIndex <= maxIndex;
if (unreadActionVisible && hasUnreadMarkerReportAction) {
    setIsFloatingMessageCounterVisible(false);
}

This assumes "if you can see the New marker, you can see all the new messages" — only true when the entire unread block fits in one viewport. For incoming messages there's no fallback auto-scroll either: useReportActionsNewActionLiveTail.ts:82-84 returns early for any action that isn't isFromCurrentUser, by design relying on the pill — which is exactly what's broken.

Evidence trace

• Mount position: initialScrollKey = linkedReportActionID ?? unreadMarkerReportActionID → list opens at the marker, not the bottom.
• Pill gating: unreadActionVisible only checks the marker index against the visible range (minIndex/maxIndex). It never checks whether the newest action (index 0 in the inverted list) is visible.
• No auto-scroll for recipient: scrollToBottomForCurrentUserAction bails when !isFromCurrentUser, so a recipient who is sitting in the chat as messages arrive gets neither a scroll nor (because the marker stays in view) a pill.

This explains both reported scenarios — returning to a chat (Scenario A) and messages arriving while present (Scenario B) — since both end with the marker visible but newer messages below the fold.

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

Gate the pill on whether the newest (bottom) action is visible, not solely on whether the unread marker is visible.

In onViewableItemsChanged (useReportUnreadMessageScrollTracking.ts:128-137):

• Compute whether the bottom is in view. In the inverted list the newest action is index 0, so the bottom is visible when minIndex === 0 and there are no newer actions to load (!hasNewerActions).
• Show the pill when there are unread messages AND the bottom is not visible (replacing the marker-only !unreadActionVisible check).
• Only hide the pill when the bottom is actually reached.

This way, landing at the marker with more messages below the fold keeps the pill visible until the user scrolls to the newest message. The existing "mark as read" trigger (lines 140-144) can keep using marker visibility — only the pill show/hide gate needs to change.

What alternative solutions did you explore? (Optional)

Auto-scrolling recipients to the bottom on incoming messages was considered but rejected — it would steal the reading position from a user mid-scroll, which is why the current design deliberately keeps recipients in place and relies on the pill.

Possibly related issues (not deduped)

• [$250] Messages - Latest message instead of marked as unread after clicking 'New messages' #44647 — "Latest message instead of marked as unread after clicking 'New messages'"
• [Due for payment 2026-10-07] [$250] Chat- "New messages" doesn't jump directly to the message marked as Unread for second time #12249 — "'New messages' doesn't jump directly to the message marked as Unread"

These touch the same unread-marker/pill subsystem but describe different symptoms.

---

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

[lorretheboy]

Proposal

What is the root cause of that problem?

The floating "New messages" pill visibility is tied to the unread marker's visibility, not to whether the newest message is actually on screen.

In useReportUnreadMessageScrollTracking.ts, unreadActionVisible is true the moment the unread marker row enters the viewport, and that immediately force-hides the pill:

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

Lines 128 to 137 in 526687f

	const unreadActionVisible = isInverted ? unreadActionIndex >= minIndex : unreadActionIndex <= maxIndex;
	// 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);
	}

The implicit assumption is "marker visible ⇒ all new messages visible." That only holds when the whole unread block fits in one viewport. When you return to a chat with many unread messages, initialScrollKey lands the list at the marker, placing it near the top of the viewport with the newer messages below the fold. The marker is technically visible → the pill is suppressed → you never learn there are more messages underneath.

This compounds with the auto-scroll path, which intentionally only jumps to the bottom for messages from the current user, leaving recipients to depend on the (now-suppressed) pill:

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

Lines 80 to 93 in 526687f

	// If a new comment is added and it's from the current user scroll to the bottom otherwise leave the user positioned where
	// they are now in the list.
	if (!isFromCurrentUser || (!isReportTopmostSplitNavigator() && !Navigation.getReportRHPActiveRoute())) {
	return;
	}
	if (!hasNewestReportAction && !isFromCurrentUser) {
	if (Navigation.getReportRHPActiveRoute()) {
	return;
	}
	Navigation.setNavigationActionToMicrotaskQueue(() => {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID));
	});
	return;
	}

So the causal chain: incoming messages don't auto-scroll → recipient must rely on the pill → pill is gated on marker visibility instead of bottom visibility → landing at the marker (with messages below) hides the pill → unread messages stay off-screen with no indicator.

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

Gate the hide on the newest/bottom action being visible rather than on the marker being visible. In this inverted list the newest action sits at index 0, so the bottom is on screen only when minIndex === 0 and there are no newer actions to load (!hasNewerActions).

Change the hide branch in onViewableItemsChanged so it only hides when the bottom is actually reached:

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

Lines 128 to 137 in 526687f

	const unreadActionVisible = isInverted ? unreadActionIndex >= minIndex : unreadActionIndex <= maxIndex;
	// 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);
	}

Concretely, compute a bottomVisible flag (isInverted ? minIndex === 0 : maxIndex === lastIndex) combined with !hasNewerActions, and use that for the hide condition while keeping the "show when marker is out of view" behavior. This way, landing at the marker with messages still below the fold keeps the ↓ New messages pill visible until the user reaches the newest message; the mark-as-read on reaching the bottom continues to work as before.

What alternative solutions did you explore? (Optional)

In useReportActionsNewActionLiveTail.ts, also surface the pill (rather than doing nothing) for incoming messages when the bottom isn't visible — but that's a secondary safety net; fixing the visibility gate at the single convergence point in useReportUnreadMessageScrollTracking.ts resolves both Scenario A and B.

Recording for bug reproduction

bug.mov

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-09 18:49:59 UTC.

Proposal

What is the root cause of that problem?

When opening an unread report, the app intentionally anchors the report actions list to the oldest unread action. That makes the New marker visible, but it does not mean the newest unread action is visible.

The floating counter currently treats those as the same thing. useReportUnreadMessageScrollTracking hides the pill as soon as the unread marker is considered visible, so returning to a chat at the first unread message suppresses New messages even when newer unread messages are still below the fold or still need to be loaded.

Incoming messages do not rescue this path because the live-tail hook only scrolls automatically for the current user's own actions. For messages from someone else, the floating counter is the intended signal.

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

Update useReportUnreadMessageScrollTracking so unread-marker visibility is used only for marker/read bookkeeping, not as the sole condition for hiding the floating counter.

For the main report list, pass the actual newest rendered report action into the hook, preferably by report action ID rather than only by index because useFlashListScrollKey temporarily slices the data while anchoring to initialScrollKey. In the hook, when an unread marker exists, show the pill unless the actual newest action is viewable and there are no newer actions left to load. Keep the existing readNewestAction behavior tied to the unread marker becoming visible.

Update the non-inverted MoneyRequestReportActionsList caller at the same time so it passes its own newest action explicitly. Preserve the existing scroll-offset threshold behavior for already-read reports with no unread marker, and do not change backend/API behavior or unread-marker eligibility rules.

Add/adjust unit tests for:

• unread marker visible but newest action not visible: pill stays visible
• unread marker and newest action visible with no newer pages: pill hides
• unread marker visible while hasNewerActions is true: pill stays visible
• the existing no-unread-marker threshold behavior

What alternative solutions did you explore? (Optional)

I considered auto-scrolling for incoming messages, but the current live-tail logic deliberately avoids moving recipients away from their current position. I also considered changing the initial unread anchor placement, but that would only work for some viewport sizes; the reliable signal is whether the user has actually reached the newest action.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.