[$250] Search - Report always auto scroll down after editing the expense from RHP

[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: 9.0.7-3 Reproducible in staging?: Y Reproducible in production?: N Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat
3. Submit two expenses
4. Go to transaction thread of any of the expenses
5. Send enough messages so that the thread is scrollable
6. Scroll up and click on any field
7. Edit the field and save it
8. Note that the report does not auto scroll down
9. Go to Search
10. Open the report RHP for the same transaction thread
11. Scroll up, click on any field, edit and save it

Expected Result:

The report will not auto scroll down after editing the expense

Actual Result:

The report always auto scroll down after editing the expense from RHP

Workaround:

Unknown

Platforms:

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

• [x] Android: Native
• [x] Android: mWeb Chrome
• [x] iOS: Native
• [x] iOS: mWeb Safari
• [x] MacOS: Chrome / Safari
• [x] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/user-attachments/assets/bf14a155-29d7-4143-943e-995415bd8dfa

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01254f76c66b3ced64
• Upwork Job ID: 1812983922733611293
• Last Price Increase: 2024-07-22
• Automatic offers:
• alitoshmatov | Reviewer | 103286918

[melvin-bot[bot]]

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

[github-actions[bot]]

:wave: 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.

[lanitochka17]

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

[aldo-expensify]

This behaviour is also in production, so removing the deploy blocker label:

https://github.com/user-attachments/assets/3dc3b026-b80b-43f9-90fc-75caa5c2fbcd

[melvin-bot[bot]]

Triggered auto assignment to @greg-schroeder (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.

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~01254f76c66b3ced64

[melvin-bot[bot]]

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

[bernhardoj]

Proposal

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

The report chat list always scroll to bottom when editing the money request info if we open it from the search page.

What is the root cause of that problem?

When we open the report screen from the search page, it's inside an RHP navigator. In RHP navigator, a previous screen is hidden, that is the display is set to 'none' (you can check this yourself from the element inspector). In our case, when we open the report RHP, and then open the description page, the report RHP is hidden.

The list in the report screen uses a custom FlatList which sets up a mutation observer. The mutation observer will scroll to the last scroll offset if it's different than the current offset. https://github.com/Expensify/App/blob/7d58aa6694f8ef6eb298c35526a154f7e374fdd6/src/components/FlatList/index.tsx#L123-L134

We continuously save the last scroll offset here. https://github.com/Expensify/App/blob/7d58aa6694f8ef6eb298c35526a154f7e374fdd6/src/components/FlatList/index.tsx#L77-L78

But somehow, after updating the money request, the last scroll offset is 0 and the current scroll offset is the correct scroll offset. That is because, when a view has a display of none, the scroll offset is 0 (scrollTop). https://github.com/Expensify/App/blob/7d58aa6694f8ef6eb298c35526a154f7e374fdd6/src/components/FlatList/index.tsx#L50-L55

The flow is like this:

1. Open the description page, report RHP is hidden
2. Update the description, a system message that the description is added. This triggers the first mutation observer. The last scroll offset contains the prev scroll offset, but the current scroll offset is 0. This calls scrollToOffset to the last scroll offset (the correct scroll offset).
3. The mutation observer calls prepareForMaintainVisibleContentPosition which updates the last scroll offset to the current scroll offset, that is 0.
4. The list is displayed, trigger the second mutation observer. At this point, the prev scroll offset is 0 and the current scroll offset is the correct offset. This calls scrollToOffset to the last scroll offset, 0, to the bottom.

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

Ignore the mutation observer if the list is hidden.

One way to check if it's hidden is to check whether the height is 0 or not. A hidden view will have a height (or width) of 0. https://github.com/Expensify/App/blob/7d58aa6694f8ef6eb298c35526a154f7e374fdd6/src/components/FlatList/index.tsx#L123-L134

if (!getScrollableNode(scrollRef.current)?.clientHeight) {
    return;
}

OR

Don't save the scroll offset in prepareForMaintainVisibleContentPosition if the list is still hidden.

https://github.com/Expensify/App/blob/7d58aa6694f8ef6eb298c35526a154f7e374fdd6/src/components/FlatList/index.tsx#L72-L78

if (contentView == null || !getScrollableNode(scrollRef.current)?.clientHeight/clientWidth) {

[greg-schroeder]

Proposal review underway

[melvin-bot[bot]]

@greg-schroeder, @alitoshmatov, @aldo-expensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[greg-schroeder]

bump @alitoshmatov

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

@greg-schroeder, @alitoshmatov, @aldo-expensify Still overdue 6 days?! Let's take care of this!

[alitoshmatov]

Reviewing

[alitoshmatov]

@bernhardoj Thank you for your proposal, your RCA is correct and you solution does makes and works. I think we can go with your first solution

We can go with @bernhardoj 's proposal

C+ reviewed 🎀 👀 🎀

[melvin-bot[bot]]

Current assignee @aldo-expensify is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[aldo-expensify]

Do we really want it to scroll down when you edit a report's field to show you the automatic message? What if you wanted to edit two or three fields? if it scrolls down automatically it would very annoying to have to scroll up for each field you want to change.

I'm going to ask in slack if this is something we really want: https://expensify.slack.com/archives/C01GTK53T8Q/p1722026364959159

[melvin-bot[bot]]

📣 @alitoshmatov 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job

[aldo-expensify]

I misunderstood the issue and it was the opposite, assigning @bernhardoj !

[bernhardoj]

PR is ready

cc: @alitoshmatov

[greg-schroeder]

bump @alitoshmatov on PR review

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

• https://github.com/Expensify/App/pull/46353

If no regressions arise, payment will be issued on 2024-08-13. :confetti_ball:

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

• @bernhardoj requires payment through NewDot Manual Requests
• @alitoshmatov requires payment automatic offer (Reviewer)

[melvin-bot[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:

• [ ] [@alitoshmatov] The PR that introduced the bug has been identified. Link to the PR:
• [ ] [@alitoshmatov] 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:
• [ ] [@alitoshmatov] 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:
• [ ] [@alitoshmatov] Determine if we should create a regression test for this bug.
• [ ] [@alitoshmatov] 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.
• [ ] [@greg-schroeder] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[greg-schroeder]

Processing

[greg-schroeder]

Payment summary:

Contributor: @bernhardoj - $250 - You can make a manual request via ND C+: @alitoshmatov - $250 - Paid via Upwork

cc @alitoshmatov can you complete the checklist so we can close this out? Thanks!

[bernhardoj]

Requested in ND.

[JmillsExpensify]

$250 approved for @bernhardoj

[aldo-expensify]

Friendly bump @alitoshmatov on completing the list

[melvin-bot[bot]]

@greg-schroeder, @bernhardoj, @alitoshmatov, @aldo-expensify Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[alitoshmatov]

• The PR that introduced the bug has been identified. Link to the PR: https://github.com/Expensify/App/pull/32098
• 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: https://github.com/Expensify/App/pull/32098/files#r1720975881
• 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: No need
• Determine if we should create a regression test for this bug. No need

[aldo-expensify]

@greg-schroeder was everyone payed? are we ready to close this?

[greg-schroeder]

yup! closing