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
[$250][HOLD #49825][HOLD #49824] Chat - Chat is not autoscrolled to the bottom when receiving whisper after a mention #49599
Version Number: 9.0.39.0 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: N/A Issue reported by: Applause - Internal Team
Action Performed:
Open the staging.new.expensify.com website
Open any room chat in inbox
Mention another user that is not a member of that room
Verify that a whisper is received afrer sending the mention, and the chat is autoscrolled to the bottom
Expected Result:
After mentioning another user that is not part of the chat, a whisper with options should be received, and the chat should be autoscrolled to the bottom
Actual Result:
When the whisper is received, after mentioning an user that is not part of the room, the chat is not autoscrolled to the bottom
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
@RachCHopkins FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors
changed the title [-]Chat - Chat is not autoscrolled to the bottom when receiving whisper after a mention[/-][+][$250] Chat - Chat is not autoscrolled to the bottom when receiving whisper after a mention[/+]on Sep 24, 2024
Edited by proposal-police: This proposal was edited at 2024-09-27 08:30:08 UTC.
Proposal
Please re-state the problem that we are trying to solve in this issue.
When a whisper is received in the chat for the current user the screen is not scrolled down and the whisper is not visible until the user decides to scroll down.
What is the root cause of that problem?
The cause of the issue seems to be an intented behaviour in the logic of the scrolling for new actions. The current logic scrolls the user to the bottom if the action is from the current user, all other cases no scrolling is done. This logic is in ReportActionsList.tsx in this code block:
const scrollToBottomForCurrentUserAction = useCallback(
(isFromCurrentUser: boolean) => {
// 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) {
return;
}
if (!hasNewestReportActionRef.current) {
Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID));
return;
}
InteractionManager.runAfterInteractions(() => reportScrollManager.scrollToBottom());
},
[reportScrollManager, report.reportID],
);
What changes do you think we should make in order to solve the problem?
We have a few options depending on how the scrolling is intented to behave;
Always scroll down for all new actions not just for current user messages. This is a very easy fix, we just remove the !isFromCurrentUser check.
Scroll down only for messages from the current user and whispers of the current user. First part is the existing logic, we need to add another code block that would check if the action is a whisper for the current user.
After the isFromCurrentUser check would be replaced by the following block:
Option 2 does not work when the device or internet is slow because it triggers an auto scroll when the action is created, i.e when the user sends the message, but the whisper itself comes as another action a later point from the BE.
We need to change the approach to check the latest action in the chat and check if that is a whisper for the current user or not by changing this existing useEffect to this:
In addition we need to fix how the hasNewestReportAction is calculated by replacing hasNewestReportAction = sortedVisibleReportActions[0]?.created === report.lastVisibleActionCreated with: hasNewestReportAction = sortedVisibleReportActions[0]?.created >= report.lastVisibleActionCreated. Up to this point we had assumed that the sortedVisibleReportActions[0]?.created is always equal to report.lastVisibleActionCreated but for some reason the optimistic data are a bit behind the actual BE.
What alternative solutions did you explore? (Optional)
@klajdipaja is correct – this looks intentional at the moment. However, it seems reasonable to also enable auto-scroll on the whispers as they are system messages addressed directly to the user and often require some action/attention.
🎀👀🎀 C+ reviewed to summon an Engineer for decision.
so for #49599 (comment) I think that might be expected? What's the behavior if someone sends a regular message when you're scrolled up in the chat, like you are? I don't think you should be rescrolled to the bottom, right?
You're right 👍 This GH seems to be resolved now.
How do we act if the Contributor has already been hired here but the PR has not been opened because we had to hold? Do we just close the issue?
Activity
melvin-bot commentedon Sep 23, 2024
Triggered auto assignment to @RachCHopkins (
Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.lanitochka17 commentedon Sep 23, 2024
@RachCHopkins FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors
RachCHopkins commentedon Sep 24, 2024
Fine on web/desktop.
Same on iOS native app. Not just android/web, my guess is that it's anything with a mobile aspect ratio.
[-]Chat - Chat is not autoscrolled to the bottom when receiving whisper after a mention[/-][+][$250] Chat - Chat is not autoscrolled to the bottom when receiving whisper after a mention[/+]melvin-bot commentedon Sep 24, 2024
Job added to Upwork: https://www.upwork.com/jobs/~021838383119719075523
melvin-bot commentedon Sep 24, 2024
Triggered auto assignment to Contributor-plus team member for initial proposal review - @paultsimura (
External)klajdipaja commentedon Sep 24, 2024
Edited by proposal-police: This proposal was edited at 2024-09-27 08:30:08 UTC.
Proposal
Please re-state the problem that we are trying to solve in this issue.
When a whisper is received in the chat for the current user the screen is not scrolled down and the whisper is not visible until the user decides to scroll down.
What is the root cause of that problem?
The cause of the issue seems to be an intented behaviour in the logic of the scrolling for new actions. The current logic scrolls the user to the bottom if the action is from the current user, all other cases no scrolling is done. This logic is in
ReportActionsList.tsxin this code block:What changes do you think we should make in order to solve the problem?
We have a few options depending on how the scrolling is intented to behave;
!isFromCurrentUsercheck.After the
isFromCurrentUsercheck would be replaced by the following block:We need to change the approach to check the latest action in the chat and check if that is a whisper for the current user or not by changing this existing useEffect to this:
In addition we need to fix how the
hasNewestReportActionis calculated by replacinghasNewestReportAction = sortedVisibleReportActions[0]?.created === report.lastVisibleActionCreatedwith:hasNewestReportAction = sortedVisibleReportActions[0]?.created >= report.lastVisibleActionCreated. Up to this point we had assumed that the sortedVisibleReportActions[0]?.created is always equal to report.lastVisibleActionCreated but for some reason the optimistic data are a bit behind the actual BE.What alternative solutions did you explore? (Optional)
paultsimura commentedon Sep 24, 2024
@klajdipaja is correct – this looks intentional at the moment. However, it seems reasonable to also enable auto-scroll on the whispers as they are system messages addressed directly to the user and often require some action/attention.
🎀👀🎀 C+ reviewed to summon an Engineer for decision.
57 remaining items
paultsimura commentedon Nov 19, 2024
You're right 👍 This GH seems to be resolved now.
How do we act if the Contributor has already been hired here but the PR has not been opened because we had to hold? Do we just close the issue?
paultsimura commentedon Nov 19, 2024
Apparently, we had a GH for it that got closed due to being a non-priority. You could take a look there, it was diagnosed as a BE issue: #47255
dangrous commentedon Nov 19, 2024
Okay great, then I think we're good to close this! Since no PR raised, I don't think we need payment here but if anyone disagrees let me know. Thanks!
klajdipaja commentedon Nov 19, 2024
@dangrous @paultsimura what should be done with the Upwork contract in this case?
paultsimura commentedon Nov 19, 2024
@klajdipaja we can just close it by ourselves. Specify "the work is no longer needed" as the reason.
dangrous commentedon Nov 19, 2024
actually, I've been informed that we pay 50% in this case (contributor hired but no PR needed)! @RachCHopkins can you help us out?
RachCHopkins commentedon Nov 19, 2024
Payment Summary:
Upwork job here
paultsimura commentedon Nov 19, 2024
Thanks.
@RachCHopkins what is the payment date supposed to be here?
dangrous commentedon Nov 21, 2024
I think we can pay whenever, since it was only backend we're not waiting on a regression period cc @RachCHopkins
RachCHopkins commentedon Nov 22, 2024
@paultsimura it's ASAP! I'm just getting my ducks in a row! 🦆 🦆🦆
RachCHopkins commentedon Nov 22, 2024
Contributors have been paid, the contracts have been completed, and the Upwork post has been closed.