[HOLD for payment 2024-04-09] [$500] Expense - Page scrolls back down when dismissing add receipt RHP in transaction thread

[lanitochka17]

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: 1.4.56-2
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by:
Slack conversation:

Action Performed:

1. Go to staging.new.expensify.com
2. Create a manual request without receipt
3. Go to request details page
4. Scroll to the top of the page
5. Click on add receipt thumbnail
6. Click outside the RHP to dismiss it

Expected Result:

The page will not scroll down when closing the RHP (production behavior)

Actual Result:

The page scrolls down when closing the RHP

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6425973_1711372872772.20240325_151949.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01e4b313e99e0a0eca
• Upwork Job ID: 1772334661375188992
• Last Price Increase: 2024-03-25

Issue Owner

Current Issue Owner: @mananjadhav

[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.

[melvin-bot]

Triggered auto assignment to @flodnv (Engineering), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[lanitochka17]

We think that this bug might be related to #wave-collect - Release 1

[lanitochka17]

@flodnv 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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01e4b313e99e0a0eca

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[habasefa]

I couldn't reproduce this on dev but it is still there on staging.

[abzokhattab]

Proposal

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

Page scrolls back down when dismissing add receipt RHP in transaction thread

What is the root cause of that problem?

the app makes a request to openReport everytime we dismiss the RHP panel because of the following useEffect which was introduced in this PR

App/src/pages/home/ReportScreen.tsx

Lines 430 to 439 in 6873f24

	// If a user has chosen to leave a thread, and then returns to it (e.g. with the back button), we need to call `openReport` again in order to allow the user to rejoin and to receive real-time updates
	useEffect(() => {
	if (!isFocused || prevIsFocused || !ReportUtils.isChatThread(report) || report.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN) {
	return;
	}
	Report.openReport(report.reportID);
	// We don't want to run this useEffect every time `report` is changed
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [prevIsFocused, report.notificationPreference, isFocused]);

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

1. as @perunt shared here, the useEffect was introduced to fix a bug in the small devices only, the issue didn't happen with wide devices so as suggested we can add another condition so that it returns if the current device is not small:

        if (!isFocused || prevIsFocused || !ReportUtils.isChatThread(report) || !isSmallScreenWidth || report.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN) {

2. or can add a condition to return if report is a money request report, to achieve that we should add ReportUtils.isMoneyRequest(report) to the condition above, or we can use ReportUtils.isPolicyExpenseChat(report):

     if (
            !isFocused ||
            prevIsFocused ||
            !ReportUtils.isChatThread(report) ||
            ReportUtils.isMoneyRequest(report) ||
            report.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN
        ) {

alternatively

since the previous useEffect was implemented to handle the reloading of the report when leaving a thread and then going back to it. We can address this issue differently using Onyx:

We can introduce a new boolean value, shouldReloadReport, within the report to determine if the report needs to be reloaded. This value will be set to true when leaving a thread (within the optimistic values of the leave thread function). Then, within the useEffect, we should only open the report if shouldReloadReport is true. then after the report has been successfully opened, we should reset shouldReloadReport to false.

[ghost]

If it is caused by this PR then is it not a regression?

[flodnv]

+1, are we saying the bug is reproducible on production?

[flodnv]

I can confirm this bug is reproducible only in staging and not on production.

[yuwenmemon]

Taking over for @flodnv who needs to run

[yuwenmemon]

The proposal by @abzokhattab is not the solution, we still call OpenReport on production just fine when dismissing the modal:

[abzokhattab]

i see .. but why would we send an openReport request every time we dismiss the RHP?

when dismissing the panel, the report data should be the same, so there is no need to send an openReport request in this case (redundant requests).

[yuwenmemon]

@abzokhattab Fair point, but I don't think that's a concern for this issue. Feel free to bring up that concern in #expensify-open-source 🙂

[abzokhattab]

Okay, started a conversation here on slack

[yuwenmemon]

Still looking for reasons why the scrolling is happening and possible solutions, but this is a minor issue so I won't let this block the deploy.

[melvin-bot]

Triggered auto assignment to @kadiealexander (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[perunt]

Okay, so just to recap, the issue occurs when we call OpenReport upon clicking outside the RHP. The PR that introduced this behavior seems to be the source. It appears the prevIsFocused value acts differently when the screen is wide or small, resulting in OpenReport being called when there is no need for it.
Here prevIsFocused changed twice when i close the window:

Firstly, it's important to note that this fix is only valid for mobile devices. The bug was originally a mobile-only issue based on my testing. The behavior of prevIsFocused differs between web and mobile platforms, which means it's not a suitable basis for this fix.

I tried using const join = Session.checkIfActionIsAllowed(() => {..., and it successfully receives all necessary props. This leads me to believe that we can address the issue without resorting to calling OpenReport.

Given the numerous blockers we're facing, I need to jump on them :). Therefore, as a temporary solution, I suggest adding isSmallScreenWidth to this line in ReportScreen.tsx. This adjustment would prevent OpenReport from being called and eliminate unnecessary scrolling on wide screens. For small screens, scrolling might still occur if there are no messages following this report action, but this is a rare case. Even if it happens, the scrolling is not significant—typically, it's up to half the screen height.

So, TL;DR: We've gotta avoid calling OpenReport, I believe, or better yet, cut it out entirely. For now, I’m pitching a one-liner as a temporary fix. It doesn’t introduce any new 'bad' code, just extends an existing hack.
cc @yuwenmemon

[abzokhattab]

thanks @perunt, that's a very good observation, i have updated my proposal to check for the isSmallScreenWidth in the condition.and its seems to fix the issue for me as well.

[perunt]

It doesn't fix the origin of the issue, which I believe is this PR
@roryabraham if you're good with it, we can fix with PR

[yuwenmemon]

@perunt Sounds good to me - can we prep the PR for review?

[abzokhattab]

@yuwenmemon @perunt @roryabraham let me know what you think about the alternative proposal here, it fixes the join issue in a more robust way which doesn't cause the current issue or any other issue related to the current useEffect ... let me know also if you need the implementation details.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.58-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Auto scroll fix #38999

If no regressions arise, payment will be issued on 2024-04-09. 🎊

For reference, here are some details about the assignees on this issue:

• @mananjadhav requires payment through NewDot Manual Requests

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@mananjadhav] The PR that introduced the bug has been identified. Link to the PR: https://github.com/Expensify/App/pull/38027/files#diff-68b13bc8344820144538408415f307efee198ccc63977ba318c4234102ec3917
• [@mananjadhav] 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: [HOLD for payment 2024-04-09] [$500] Expense - Page scrolls back down when dismissing add receipt RHP in transaction thread #38935 (comment)
• [@mananjadhav] A discussion in #expensify-bugs 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: [HOLD for payment 2024-04-09] [$500] Expense - Page scrolls back down when dismissing add receipt RHP in transaction thread #38935 (comment)
• [@mananjadhav] Determine if we should create a regression test for this bug.
• [@mananjadhav] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@kadiealexander] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[kadiealexander]

@mananjadhav please complete the checklist!

[mananjadhav]

Thanks for the bump @kadiealexander. We already discussed the offending PR with the explanation.

I don't think we need a regression test for this one.

[melvin-bot]

Payment Summary

Upwork Job

• Reviewer: @mananjadhav owed $500 via NewDot

BugZero Checklist (@kadiealexander)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1772334661375188992/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[JmillsExpensify]

$500 approved for @mananjadhav based on checklist above.