Status - Inconsistent behavior when closing status RHP

[kbecciv]

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

Action Performed:

Precondition: User has a custom status.

1. Go to staging.new.expensify.com.
2. On home page, click on status icon on the user avatar.
3. Click outside the status RHP.
4. Return to main chat.
5. Click on status icon.
6. Click back button on the RHP.

Expected Result:

There should be consistent behavior when closing status RHP when clicking outside the RHP and clicking back button on RHP.

Actual Result:

In Step 6, when clicking back button on the status RHP, it closes both profile page and also status RHP.
On Android app, the back button on status page redirects user to the home page, while the device back navigation on status page reveals the profile page underneath.

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

Bug6365303_1706906464990.20240203_041534.mp4

View all open jobs on GitHub

[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 @roryabraham (Engineering), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[kbecciv]

We think that this bug might be related to #vip-vsb
CC @quinthar

[bernhardoj]

Proposal

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

Pressing the status page back button takes the user back to the report screen.

What is the root cause of that problem?

If we press the overlay, it simply calls goBack which will close the status page.

App/src/libs/Navigation/AppNavigator/Navigators/RightModalNavigator.tsx

Lines 28 to 34 in 3ab4e6e

	<Overlay
	onPress={() => {
	if (isExecutingRef.current) {
	return;
	}
	isExecutingRef.current = true;
	navigation.goBack();

But if we press the status page back button, it will pop all screens (shouldPopToTop is true)

App/src/pages/settings/Profile/CustomStatus/StatusPage.js

Line 73 in 3ab4e6e

const navigateBackToPreviousScreen = useCallback(() => Navigation.goBack('', false, true), []);

App/src/libs/Navigation/Navigation.ts

Lines 177 to 183 in 3ab4e6e

	if (shouldPopToTop) {
	if (shouldPopAllStateOnUP) {
	shouldPopAllStateOnUP = false;
	navigationRef.current?.dispatch(StackActions.popToTop());
	return;
	}
	}

and only happens if we press the status icon.

App/src/pages/home/sidebar/AvatarWithOptionalStatus.js

Lines 38 to 39 in 3ab4e6e

	Navigation.setShouldPopAllStateOnUP();
	Navigation.navigate(ROUTES.SETTINGS_STATUS);

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

I think the pop to top logic is not relevant anymore for status page after the navigation change because the setting page always open, so we can update the go back code in status page to simply call goBack.

What alternative solutions did you explore? (Optional)

Call setShouldPopAllStateOnUP only for small screen, but it would be weird if we resize from small to large screen.

Or we can keep calling setShouldPopAllStateOnUP and pass shouldPopToTop to goBack only if it's a small screen.

Navigation.goBack('', false, isSmallScreenWidth)

[mountiny]

Demoting this issue from deploy blocker, this was kinda known before the merge and related to goBack functionality.

@adamgrzybowski Could you please look into the proposal from @bernhardoj to see whether we should go with it or wait for the more generic goBack fix ? Thanks!

[hayata-suenaga]

All back issues are tracked in this issue, and I have added this particular issue to it as well. 👍

[mountiny]

Making this weekly given its part of a bigger scheme

[adamgrzybowski]

Probably mentioned somewhere but it should be fixed by this PR

[melvin-bot]

This issue has not been updated in over 15 days. @mountiny, @hayata-suenaga eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[hayata-suenaga]

Probably mentioned somewhere but it should be fixed by this #36050

Screen.Recording.2024-03-04.at.11.05.56.AM.mov

confirmed the issue was fixed on production. closing the issue