[Due for payment 2026-04-28] Web - Comment/ expense not highlighted when hovered upon in a conversation after pasting

[nlemma]

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: v9.3.60-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: N/A
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Windows 11/ Chrome
App Component: Chat Report View

Action Performed:

1. Sign in to staging.new.expensify.com
2. Navigate to a conversation
3. Paste a text in compose box and send (copy a comment and paste in the compose box)
4. Hover over the comments in view

Expected Result:

Each comment is highlighted when hovered upon

Actual Result:

Comments are not highlighted when hovered upon and highlight function only starts working if the user scrolls through the conversation

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7131177_1776323093615.bandicam_2026-04-16_10-03-21-093.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @situchan

[melvin-bot]

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

[MelvinBot]

Proposal

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

After pasting text in the compose box and sending a message, hovering over comments no longer highlights them. Hover highlighting only resumes after the user manually scrolls.

What is the root cause of that problem?

Bug in useEmitComposerScrollEvents — when the first scroll event fires, it emits SCROLLING: true but never schedules SCROLLING: false.

The key logic error is on line 81: the setTimeout that emits SCROLLING: false is only scheduled when lastScrollEvent.current is truthy, but on the first call it's null (initialized on line 21). So lastScrollEvent.current gets set to the timestamp after the check, but the timeout is never created.

When a message is sent, the list auto-scrolls via scrollToOffset({animated: false, offset: 0}) which fires exactly one scroll event. That single event hits this first-call bug: SCROLLING: true is emitted, SCROLLING: false never follows. ActiveHoverable suppresses all hover updates while isScrollingRef.current is true, so hover highlighting breaks globally.

Manual scrolling generates multiple scroll events — the second event finds lastScrollEvent.current truthy, properly schedules the timeout, and SCROLLING: false eventually fires, restoring hover.

This is web-only because the native implementation is a no-op.

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

Move the lastScrollEvent.current = timestamp assignment before the if (lastScrollEvent.current) check, or remove the guard entirely so the timeout is always scheduled (matching the pattern in useScrollEventEmitter which correctly always schedules the timeout).

Specifically in src/hooks/useEmitComposerScrollEvents/index.ts, change emitComposerScrollEvents to:

const emitComposerScrollEvents = () => {
    if (!enabled || !inverted) {
        return;
    }

    onScroll();

    const timestamp = Date.now();

    if (scrollEndTimeout.current) {
        clearTimeout(scrollEndTimeout.current);
    }

    // Always schedule the scroll-end timeout (removed the lastScrollEvent.current guard)
    scrollEndTimeout.current = setTimeout(() => {
        if (lastScrollEvent.current !== timestamp) {
            return;
        }
        lastScrollEvent.current = null;
        onScrollEnd();
    }, 250);

    lastScrollEvent.current = timestamp;
};

Investigation details

Evidence chain:

1. PureReportActionItem wraps each action in <Hoverable shouldHandleScroll> (PureReportActionItem.tsx:1648)
2. ActiveHoverable listens for SCROLLING events and suppresses hover when scrolling is true (ActiveHoverable.tsx:30-32, ActiveHoverable.tsx:50-61)
3. FlashList wraps the report actions list and calls emitComposerScrollEvents() on every scroll (FlashList/index.tsx:10-14)
4. After sending a message, scrollToBottom fires a non-animated scroll (useReportScrollManager/index.ts:23-29)
5. The bug in useEmitComposerScrollEvents means a single scroll event leaves SCROLLING stuck as true

Comparison with useScrollEventEmitter: The older useScrollEventEmitter hook (used by LHN and other lists) does not have this bug — it always schedules the SCROLLING: false timeout unconditionally on every call.

Introduced in: PR #87418, which created the useEmitComposerScrollEvents hook.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.