[$1000] Web - Back button after page reload does not work properly on profile page

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

---

Action Performed:

1. Create new a group and invite someone
2. Click header to open details page
3. Click one of row
4. Click back button, Observe the correct back to the details page
5. Click one row again
6. Reload page
7. Click back button, observed back to home

Expected Result:

After reloading the page, pressing the back button still goes back to the details page

Actual Result:

After reloading the page, pressing the back button goes back to home

Workaround:

Unknown

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.40-3
Reproducible in staging?: y
Reproducible in production?: y
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
Notes/Photos/Videos: Any additional supporting documentation

Screen.Recording.2023-07-13.at.23.57.35.mov

Recording.3619.mp4

Expensify/Expensify Issue URL:
Issue reported by: @namhihi237
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1689267806742509

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01ebbd66fe602e6683
• Upwork Job ID: 1681048622962212864
• Last Price Increase: 2023-07-17

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[adelekennedy]

This is definitely reproducible, and I can't find a dupe. i don't see this issue if I use my browser's back button though 🤷‍♀️

[ygshbht]

@adelekennedy I agree with your observation that the browser's back button doesn't reproduce the issue. This detail helps highlight the discrepancy between the app's and browser's back button behaviors.

[ygshbht]

Proposal

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

In the current application, after reloading the ProfilePage, clicking the back button navigates the user to the home screen instead of the previous participants details page. This issue is due to the app not considering the originating route when navigating back from the ProfilePage, and using a default fallback route to ROUTES.HOME.

What is the root cause of that problem?

The root cause of this issue is the limited flexibility of the back navigation logic in the ProfilePage component. The back button's action is designed to fall back to the ROUTES.HOME screen if there isn't any previous screen in the React Navigation stack.

The existing back navigation code is as follows:

<HeaderWithBackButton
    title={props.translate('common.profile')}
    onBackButtonPress={() => Navigation.goBack(ROUTES.HOME)}
/>

This issue arises when the app is reloaded on the ProfilePage without navigating from the ReportParticipantsPage first. As a result, there's no record of the previous screen in the React Navigation stack, leading the app to default to the home screen.

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

To solve this problem, we can introduce a new property fallbackRoute that can be passed to the ProfilePage component. This prop would specify the route to navigate to when the back button is pressed if there's no previous route in the navigation stack.

The back navigation code would be updated as follows:

<HeaderWithBackButton
    title={props.translate('common.profile')}
    onBackButtonPress={() => Navigation.goBack(props.fallbackRoute || ROUTES.HOME)}
/>

In the ReportParticipantsModalStackNavigator component of the ModalStackNavigators file, the code would be modified as follows:

{
    getComponent: () => {
        const ProfilePage = require('../../../pages/ProfilePage').default;
        const WrappedComponent = React.forwardRef((props, ref) => {
            return (
                <ProfilePage
                    ref={ref}
                    {...props}
                    fallbackRoute={ROUTES.getReportParticipantsRoute(props.route.params.reportID)}
                />
            );
        });
        return WrappedComponent;
    },
}

Original code:

{
        getComponent: () => {
            const ProfilePage = require('../../../pages/ProfilePage').default;
            return ProfilePage;
        },
        name: 'Profile_Root',
},

This change ensures that if a user is on the ProfilePage and reloads the application, the back button will correctly navigate back to the last visited page.

Please find the attached video demonstrating the proposed solution.

1.New.Expensify.-.Google.Chrome.2023-07-15.02-03-09.mp4

[melvin-bot]

@adelekennedy Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

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

[melvin-bot]

Current assignee @adelekennedy is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[adelekennedy]

Moving this to external

[dukenv0307]

Proposal

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

After reloading the page, pressing the back button goes back to home

What is the root cause of that problem?

When we reload the page, the App does not load the previous navigation state of the app so there's no route to go back to, so it defaults to the HOME fallback route here.

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

We need to:

1. Persist the navigation state of the app here
   More information on persisting state is in this official doc

2. When the app is loaded, if we see that the path is not home, and is the same as the path of the topmost route in the persisted navigation state (that means the user reloads the current page), we'll set the persisted state as the initial state here

3. Since only web has the concept of browser reload and have this issue, we can isolate the persistence of the navigations state to the web only.

This issue happens across the app so we can't just apply the fix in this one place, we need to do the persisted approach above to make sure reloading works well across the app.

What alternative solutions did you explore? (Optional)

We can restructure the navigation route structure so that when the profile page (that was opened from chat participants page) is loaded, it will automatically load the route before that.

But this will only fix it in this specific case.

[huzaifa-99]

I think there was a similar issue #22041 (using the save button), marked as not a bug

[s77rt]

@adelekennedy Looks like a dupe of #22041 (same root cause). Let's close this.

[dukenv0307]

@s77rt It's same root cause but I think this one clearly is buggy since it's inconsistent with the browser back button.

Also it's not clearly mentioned in the other ticket to why it was closed.
Maybe @dylanexpensify can help give some insights here as you commented there.

[greg-schroeder]

Can we take a look at #23036 as well? should we consolidate these?

[s77rt]

@greg-schroeder Yes but the previous reported issue was closed. I'm not sure if we should start fixing those issues or not.

[s77rt]

Not overdue. This is a dupe. We should probably close this one and reopen the first one (if needed).

[greg-schroeder]

Okay then. 👍