Sending a message scrolls down to previous message#54071
Conversation
|
@hoangzinh Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
| } | ||
| reportScrollManager.scrollToBottom(); | ||
| }); | ||
| Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID)); |
There was a problem hiding this comment.
Just a question, do we have any case that needs to run this navigation runAfterInteractions?
There was a problem hiding this comment.
It is to make sure that the scroll occurs after any high-priority interaction in the RN event loop, most likely animation, without it it can lead to some jerky animations or incomplete rendering.
It was already added in the code before that PR
There was a problem hiding this comment.
Yeah, you're right. I mean previously, this navigation is put inside runAfterInteractions, but with our change, it's moved outside of runAfterInteractions. I'm checking if it's safe to move outside.
There was a problem hiding this comment.
I tested it by hardcoding reportID to navigate to and I didn't see any issues. Here is an example video:
navigation.mp4
| // InteractionManager.runAfterInteractions(() => { | ||
| // 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 || scrollingVerticalOffset.current === 0) { |
There was a problem hiding this comment.
I'm worrying whether if it causes any regression with this change scrollingVerticalOffset.current === 0, can you explain why do you like to add this new condition here?
There was a problem hiding this comment.
It is just for early return, we first checks if the user is already scrolled to the bottom of the screen. If so, it immediately exits without executing any further logic and checks, cause we don't need perform scrolling in such scenario
| setPendingBottomScroll(false); | ||
| }); | ||
| } | ||
| }, [pendingBottomScroll, prevSortedVisibleReportActionsObjects, reportScrollManager, isNewMessageDisplayed]); |
There was a problem hiding this comment.
should we change isNewMessageDisplayed to use useMemo, so we don't need to pass prevSortedVisibleReportActionsObjects here?
There was a problem hiding this comment.
I replaced useCallback with useMemo, good point!
There was a problem hiding this comment.
Because isNewMessageDisplayed will be updated if prevSortedVisibleReportActionsObjects is changed. Can we remove prevSortedVisibleReportActionsObjects out of dependency list here?
@rinej can you elaborate why do we need to launch app in both mweb and app?
Can you explain this step too? Btw, @rinej we should use "Verify" to determine expected behavior, it's described here. If it's possible, can you outline by 1,2,3 numbers? For example
|
|
@hoangzinh I updated the QA steps and the description. Please let me know if it is ok. |
|
Done 👍 |
|
@rinej can you take a look at my feedback here https://github.com/Expensify/App/pull/54071/files#r1901572614? |
|
I missed the update, thank you for the ping! I am on it |
|
@rinej please don't forget to upload recordings for all platforms |
Reviewer Checklist
Screenshots/VideosAndroid: NativeScreen.Recording.2025-01-21.at.17.41.53.movAndroid: mWeb ChromeScreen.Recording.2025-01-20.at.22.10.34.android.chrome.moviOS: NativeScreen.Recording.2025-01-20.at.22.12.25.ios.moviOS: mWeb SafariScreen.Recording.2025-01-20.at.21.55.26.ios.safari.movMacOS: Chrome / SafariScreen.Recording.2025-01-20.at.21.44.00.web.movMacOS: DesktopScreen.Recording.2025-01-20.at.21.48.51.desktop.mov |
|
@rinej sometime, it doesn't work on Web Screen.Recording.2025-01-10.at.06.43.52.mov |
|
Good spot, I couldn't reproduce it for a while, but finally I saw it. However it also happens on I can investigate it further, cause this issues might be somehow related 🤔 scrollBlocksOnTop-main.mp4 |
|
@rinej, I agree that it can be reproducible on the main. But let's fix it as our expectation is "Verify that the new message is visible", otherwise we probably can't pass QA test |
|
@rinej do you mind merging latest branch 'main' to fix Eslint failed? |
|
Sure, Eslint should be fixed now |
| const lastPrevAction = prevActions.at(0); | ||
| return lastAction?.reportActionID !== lastPrevAction?.reportActionID; |
There was a problem hiding this comment.
| const lastPrevAction = prevActions.at(0); | |
| return lastAction?.reportActionID !== lastPrevAction?.reportActionID; | |
| const lastPrevVisibleAction = prevActions.at(0); | |
| return lastAction?.reportActionID !== lastPrevVisibleAction?.reportActionID; |
It's clearer if we name it like this. What do you think?
There was a problem hiding this comment.
I like that change, makes it more descriptive. I just added it
|
@rinej please also add recordings for remaining platforms (Android: mWeb Chrome, iOS: Native, iOS: mWeb Safari) |
|
I updated the new recordings and added to all platforms |
|
We did not find an internal engineer to review this PR, trying to assign a random engineer to #53685 as well as to this PR... Please reach out for help on Slack if no one gets assigned! |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/deetergp in version: 9.0.89-0 🚀
|
|
Possible regression: https://expensify.slack.com/archives/C01GTK53T8Q/p1737755959458409 |
[CP Staging] Revert PR #54071
|
🚀 Deployed to production by https://github.com/yuwenmemon in version: 9.0.89-8 🚀
|
Explanation of Change
Problem:
Currently, when a user sends a message while positioned at the top of the chat, we scroll to the bottom, even if the newly sent message is not yet visible. This makes impression that we scroll to a previous message.
Solution:
In the PR we add behavior that the chat only scrolls to the bottom if the newly sent message is actually visible to the user.
Additional Consideration:
It's worth investigating the performance of message sending, particularly on Android, as there is noticeable lag during this operation. Addressing this could significantly improve the user experience.
Before Video:
OLD_behavior.mp4
After Video:
NEW_behavior.mp4
After merging newest main and conflicts resolution:
AndroidScroll.mp4
Fixed Issues
$ #53685
PROPOSAL: #53685 (comment)
Tests
Offline tests
QA Steps
Additional tests for regular flow:
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))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
AndroidScroll.mp4
Android: mWeb Chrome
androidWeb.mp4
iOS: Native
iOS.mp4
iOS: mWeb Safari
iOSWeb.mp4
MacOS: Chrome / Safari
web.mp4
MacOS: Desktop
desktop.mp4