You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-08-25] [$250] Scroll forward immediately upon approving a report in the workspace chat #96427
When a user approves a report from the workspace chat, the forward-scroll to the next actionable item currently waits until after the approve/submit/pay button animation completes. This introduces a noticeable lag that undercuts the feature. The scroll should instead trigger immediately upon click.
Context
This is a follow-up to #94796 (the auto-scroll action pill). Once that shipped and got real usage, the delay before the scroll became a "buzzkill."
Initial assumption was that the lag was from waiting on the API response, but @aimane-chnaif clarified the wait is actually driven by the button animation (submit/approve/pay), not the API.
@aimane-chnaif noted the current post-animation timing was chosen because immediate scroll produced some weird behavior, and plans to implement the immediate-scroll approach and evaluate how it feels.
Expected Behavior
Clicking Approve (and similarly Submit/Pay) triggers the forward-scroll to the next actionable item immediately on click, rather than waiting for the button animation to finish.
Verify the immediate-scroll approach does not reintroduce the previously observed weird behavior.
🤖 Draft PR created: #98515 — please mark it Ready for review when it's ready.
What changed: The forward-scroll to the next actionable report preview now fires immediately on click (on the next frame, off the optimistic badge-target advance) instead of waiting for the submit/approve/pay button animation to finish. The resolved preview keeps playing its success animation in place while the list scrolls to the next actionable preview.
Details
The wait lived in useFollowActionBadgeTarget.ts, which delayed the scroll by getActionBadgeScrollDelay(prevActionBadge) (the full submit/approve/pay animation timeline) before scrolling. That delay was the whole reason the animation-duration helper existed, so:
useFollowActionBadgeTarget now always schedules the scroll on the next requestAnimationFrame.
Removed the now-unused getActionBadgeScrollDelay.ts helper (and its unit test) and the actionBadge/prevActionBadge plumbing.
shouldFollowActionBadgeTarget (the direction/should-follow gate) is unchanged, so the scroll still only follows the badge downward to newer actionable previews and never jumps upward/backward.
Local checks passing: oxfmt, typecheck (tsgo), eslint on changed files, react-compiler compliance, and shouldFollowActionBadgeTargetTest (9/9).
Not verified end-to-end: I couldn't run a live web smoke test — the dev session rendered a blank page with zero network activity (a bring-up failure in this environment, unrelated to a scroll-timing hook edit). Since the timing/feel difference isn't screenshot-observable anyway, the "does immediate scroll reintroduce the previously observed weird behavior?" question from the issue is best evaluated in real usage on the PR — which matches the plan to implement and evaluate how it feels.
[Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to comment: Improvement
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion:
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Open a workspace chat that has multiple report previews requiring action (e.g. several reports needing Approve/Pay), with the oldest actionable one scrolled above the current viewport.
Approve (or Pay/Submit) the oldest actionable report preview.
Verify the chat scrolls forward to the next actionable report preview.
Activity
aimane-chnaif commentedon Aug 13, 2026
@MelvinBot implement this
MelvinBot commentedon Aug 13, 2026
🤖 Draft PR created: #98515 — please mark it Ready for review when it's ready.
What changed: The forward-scroll to the next actionable report preview now fires immediately on click (on the next frame, off the optimistic badge-target advance) instead of waiting for the submit/approve/pay button animation to finish. The resolved preview keeps playing its success animation in place while the list scrolls to the next actionable preview.
Details
The wait lived in
useFollowActionBadgeTarget.ts, which delayed the scroll bygetActionBadgeScrollDelay(prevActionBadge)(the full submit/approve/pay animation timeline) before scrolling. That delay was the whole reason the animation-duration helper existed, so:useFollowActionBadgeTargetnow always schedules the scroll on the nextrequestAnimationFrame.getActionBadgeScrollDelay.tshelper (and its unit test) and theactionBadge/prevActionBadgeplumbing.shouldFollowActionBadgeTarget(the direction/should-follow gate) is unchanged, so the scroll still only follows the badge downward to newer actionable previews and never jumps upward/backward.Local checks passing:
oxfmt,typecheck(tsgo),eslinton changed files, react-compiler compliance, andshouldFollowActionBadgeTargetTest(9/9).Not verified end-to-end: I couldn't run a live web smoke test — the dev session rendered a blank page with zero network activity (a bring-up failure in this environment, unrelated to a scroll-timing hook edit). Since the timing/feel difference isn't screenshot-observable anyway, the "does immediate scroll reintroduce the previously observed weird behavior?" question from the issue is best evaluated in real usage on the PR — which matches the plan to implement and evaluate how it feels.
23 remaining items
melvin-bot commentedon Aug 20, 2026
@aimane-chnaif 6 days overdue. This is scarier than being forced to listen to Vogon poetry!
aimane-chnaif commentedon Aug 20, 2026
BugZero Checklist:
[Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to comment: Improvement
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion:
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue: https://github.com/Expensify/Expensify/issues/675554
Regression Test Proposal
Test:
Do we agree 👍 or 👎
Zapier Logs
Run ID: 00040eee-35f7-a3f6-be0c-101cd2a82064melvin-bot commentedon Aug 24, 2026
Triggered auto assignment to @mallenexpensify (
Awaiting Payment)melvin-bot commentedon Aug 24, 2026
Payment Summary
Resolving PRs:
Scroll forward immediately on approve/pay/submit instead of after button animation #98515
Reviewer: @aimane-chnaif owed $250 via NewDot
BugZero Checklist (@mallenexpensify)
mallenexpensify commentedon Aug 26, 2026
Payment Summary
Contributor+: @aimane-chnaif due $250 via NewDot
garrettmknight commentedon Sep 14, 2026
$250 approved for @aimane-chnaif