Status - Inconsistent behavior when closing status RHP

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.

Go to staging.new.expensify.com.
On home page, click on status icon on the user avatar.
Click outside the status RHP.
Return to main chat.
Click on status icon.
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?

Screenshots/Videos

Add any screenshot/video evidence

Bug6365303_1706906464990.20240203_041534.mp4

View all open jobs on GitHub

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

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

@roryabraham

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

@quinthar

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

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)

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

Making this weekly given its part of a bigger scheme

Probably mentioned somewhere but it should be fixed by this PR

@mountiny

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!

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

Navigation Menu

Repository navigation

Status - Inconsistent behavior when closing status RHP #35729

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

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

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

Status - Inconsistent behavior when closing status RHP #35729

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

github-actions commented on Feb 2, 2024

melvin-bot commented on Feb 2, 2024

kbecciv commented on Feb 2, 2024

bernhardoj commented on Feb 3, 2024

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

3 remaining items

hayata-suenaga commented on Feb 5, 2024

mountiny commented on Feb 8, 2024

adamgrzybowski commented on Feb 9, 2024

melvin-bot commented on Mar 4, 2024

hayata-suenaga commented on Mar 4, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions