Chat - Latest message floating pill appears briefly after clicking Submit floating pill

[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: 9.3.91-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87212
Email or phone of affected tester (no customers): djoijnsdojsoijnsdoijnsij1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Create two empty reports.
5. Open another chat and go back to workspace chat to get rid of new messages label.
6. Scroll to the bottom and send a message to the workspace chat.
7. Click Submit floating pill.

Expected Result:

Latest message floating pill will not appear after clicking Submit floating pill.

Actual Result:

Latest message floating pill appears briefly after clicking Submit floating pill.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7169334_1780383946205.8.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @aimane-chnaif

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

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #87212

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

Proposal

What is the root cause of that problem?

FloatingMessageCounter renders one pill inside a wrapper whose visibility is driven by an animated spring on translateY (show() → 10, hide() → -40), but the pill content is chosen synchronously from shouldShowActionBadgePill.

In this repro there is no unread marker (cleared in step 5) and the chat is shorter than the LATEST_MESSAGES_PILL_SCROLL_OFFSET_THRESHOLD (2000px), so isActive (isFloatingMessageCounterVisible) stays false the whole time. The sequence when you click the Submit pill:

1. scrollToActionBadgeTarget scrolls the target action into view.
2. The target becomes visible → isActionBadgeAboveViewport → false → shouldShowActionBadgePill → false.
3. With both isActive and shouldShowActionBadgePill now false, the wrapper starts its spring-out animation (hide()), which takes a few hundred ms.
4. But the render immediately falls into the else branch and swaps the content to the "Latest messages" pill. So while the wrapper is still on screen sliding away, the user briefly sees the "Latest messages" pill.

That brief window between the content swap and the wrapper finishing its exit animation is the flash. Because hasNewMessages is false, it's the gray "Latest messages" variant — exactly matching the issue title.

Code references (Expensify/App @ 1d4a19f)

• Content chosen synchronously by shouldShowActionBadgePill, with the unconditional "Latest messages" pill in the else branch — FloatingMessageCounter.tsx:133-152
• Animated (non-instant) wrapper exit via withSpring — FloatingMessageCounter.tsx:107-119
• scrollToActionBadgeTarget only scrolls; it does not coordinate the pill content during the transition (unlike scrollToBottomAndMarkReportAsRead just above it, which sets the counter false) — ReportActionsList.tsx:702-723
• isActionBadgeAboveViewport flips false as soon as the target enters the viewport — useReportUnreadMessageScrollTracking.ts:146-155

Alternative considered & ruled out: a genuinely scrolled-up state showing the pill. Ruled out because the offset stays under the 2000px threshold and there's no unread marker, so isFloatingMessageCounterVisible never becomes true — the pill is only visible because the wrapper is mid-exit-animation.

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

Keep the displayed pill stable while the wrapper animates out, so the content never swaps to the "Latest messages" pill during the action-badge dismissal.

In FloatingMessageCounter, drive which pill renders from a small piece of state instead of computing it inline:

• set it to the action-badge pill when shouldShowActionBadgePill is true,
• set it to the "Latest messages" pill when isActive && !shouldShowActionBadgePill,
• leave it unchanged when both are false (the dismissing case), so the exit animation finishes showing the same pill it was showing.

This way, clicking Submit scrolls to the action and the action-badge pill simply slides away — the "Latest messages" pill never flashes.

What alternative solutions did you explore? (Optional)

Gate the else branch so the "Latest messages" pill only renders when isActive is true. Simpler, but it can blank the pill mid-exit (content disappears before the wrapper finishes animating), so freezing the last-shown pill is the cleaner result.

---

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