[CP Staging] Fix hover highlight not working after sending a message#88143
[CP Staging] Fix hover highlight not working after sending a message#88143
Conversation
When a single scroll event fires (e.g. auto-scroll after sending a message), the lastScrollEvent.current ref is null on the first call. The if guard prevented scheduling the SCROLLING:false timeout, leaving hover permanently suppressed. Removing the guard ensures the timeout is always scheduled, matching the pattern in useScrollEventEmitter. Co-authored-by: Jules <Julesssss@users.noreply.github.com>
| clearTimeout(scrollEndTimeout.current); | ||
| } | ||
|
|
||
| if (lastScrollEvent.current) { |
There was a problem hiding this comment.
@MelvinBot can you find any side effects / regressions with this condition removal?
|
The condition removal is safe — no side effects or regressions. The The real guard against incorrect This also makes Pre-existing note (unrelated to this PR)
|
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / SafariScreen.Recording.2026-04-17.at.2.47.32.AM.mov |
|
The only failing check is the PR Author Checklist — this is not a code issue. All CI checks (ESLint, typecheck, tests, builds, prettier, storybook, etc.) are passing. The checklist check requires manual action (reviewing and checking off the checklist items in the PR description). |
|
The only failing check is PR Author Checklist / checklist — this is not a code failure. All code checks (ESLint, typecheck, all 8 test jobs, builds, prettier, storybook, spellcheck) are passing. The checklist check requires manual action (checking off items in the PR description) and cannot be fixed with a code change. |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
[CP Staging] Fix hover highlight not working after sending a message (cherry picked from commit f14c55a) (cherry-picked to staging by roryabraham)
|
🚧 @mountiny has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
🚀 Cherry-picked to staging by https://github.com/roryabraham in version: 9.3.60-11 🚀
Bundle Size Analysis (Sentry): |
|
No help site changes are required for this PR. This is a bug fix to internal scroll event handling ( |
|
PR pass, on Windows 11/ Chrome in v9.3.60-11 88143.mp4 |
|
🚀 Cherry-picked to staging by https://github.com/roryabraham in version: 9.3.60-12 🚀
Bundle Size Analysis (Sentry): |
|
No help site changes are required for this PR. This is an internal bug fix that removes a guard condition in the |
|
🚀 Deployed to production by https://github.com/mountiny in version: 9.3.60-22 🚀
|
|
🚀 Cherry-picked to staging by https://github.com/roryabraham in version: 9.3.61-0 🚀
Bundle Size Analysis (Sentry): |
|
No help site changes are required for this PR. The change is a purely internal bug fix to the |
Explanation of Change
Removes the
if (lastScrollEvent.current)guard inuseEmitComposerScrollEventsso the scroll-end timeout is always scheduled.On the first scroll event,
lastScrollEvent.currentisnull, so the guard prevented theSCROLLING: falsetimeout from being scheduled. After sending a message, the list auto-scrolls via a single scroll event — this hit the first-call bug and leftSCROLLINGstuck astrue, which suppressed all hover highlights until the user manually scrolled (generating a second event that cleared the state).This matches the pattern used in
useScrollEventEmitter, which unconditionally schedules the timeout.Fixed Issues
$ #88087
PROPOSAL: #88087 (comment)
Tests
Highlighted comments
Offline testsSame as above
QA Steps
Same as above
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari