[$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?

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6543218_1721078509312.scroll_4n41xoPu.mov

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]

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

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

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

Screen.Recording.2024-07-15.at.3.51.53.PM.mov

[melvin-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]

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

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

App/src/components/FlatList/index.tsx

Lines 123 to 134 in 7d58aa6

	const mutationObserver = new MutationObserver(() => {
	// This needs to execute after scroll events are dispatched, but
	// in the same tick to avoid flickering. rAF provides the right timing.
	requestAnimationFrame(() => {
	// Chrome adjusts scroll position when elements are added at the top of the
	// view. We want to have the same behavior as react-native / Safari so we
	// reset the scroll position to the last value we got from an event.
	const lastScrollOffset = lastScrollOffsetRef.current;
	const scrollOffset = getScrollOffset();
	if (lastScrollOffset !== scrollOffset) {
	scrollToOffset(lastScrollOffset, false);
	}

We continuously save the last scroll offset here.

App/src/components/FlatList/index.tsx

Lines 77 to 78 in 7d58aa6

	const scrollOffset = getScrollOffset();
	lastScrollOffsetRef.current = scrollOffset;

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

App/src/components/FlatList/index.tsx

Lines 50 to 55 in 7d58aa6

	const getScrollOffset = useCallback((): number => {
	if (!scrollRef.current) {
	return 0;
	}
	return horizontal ? getScrollableNode(scrollRef.current)?.scrollLeft ?? 0 : getScrollableNode(scrollRef.current)?.scrollTop ?? 0;
	}, [horizontal]);

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.

App/src/components/FlatList/index.tsx

Lines 123 to 134 in 7d58aa6

	const mutationObserver = new MutationObserver(() => {
	// This needs to execute after scroll events are dispatched, but
	// in the same tick to avoid flickering. rAF provides the right timing.
	requestAnimationFrame(() => {
	// Chrome adjusts scroll position when elements are added at the top of the
	// view. We want to have the same behavior as react-native / Safari so we
	// reset the scroll position to the last value we got from an event.
	const lastScrollOffset = lastScrollOffsetRef.current;
	const scrollOffset = getScrollOffset();
	if (lastScrollOffset !== scrollOffset) {
	scrollToOffset(lastScrollOffset, false);
	}

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

OR

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

App/src/components/FlatList/index.tsx

Lines 72 to 78 in 7d58aa6

	const contentView = getContentView();
	if (contentView == null) {
	return;
	}
	const scrollOffset = getScrollOffset();
	lastScrollOffsetRef.current = scrollOffset;

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

[greg-schroeder]

Proposal review underway

[melvin-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]

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

[melvin-bot]

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

[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 9.0.16-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix chat list in RHP auto scroll down when updating money request fields #46353

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

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]

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]

@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: HIGH: (Comment linking: step 2) [23220] WEB maintain visible content position #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