[HOLD for payment 2024-11-22] [$250] iOS Xero - Navigation issue when tapping app back button three times after exiting 2FA setup

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.48-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

1. Launch New Expensify app.
2. Go to workspace settings > Accounting.
3. Tap Connect next to Xero.
4. Tap Enable two-factor authentication.
5. Tap app back button.
6. Tap app back button again.
7. Note that now app returns to workspace editor.
8. Tap app back button again.

Expected Result:

App will return to workspace list.

Actual Result:

App returns to Accounting.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6633335_1728817384645.ScreenRecording_10-13-2024_18-53-12_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021845826997685288640
• Upwork Job ID: 1845826997685288640
• Last Price Increase: 2024-10-28
• Automatic offers:
• FitseTLT | Contributor | 104667848

Issue Owner

Current Issue Owner: @twisterdotcom

[melvin-bot]

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

[IuliiaHerets]

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

[IuliiaHerets]

@twisterdotcom FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[Shahidullah-Muffakir]

Edited by proposal-police: This proposal was edited at 2024-10-20 17:59:03 UTC.

Proposal

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

1. When connecting to Xero, after opening the two-factor authentication modal and tapping the back button multiple times, the app stays in the Accounting page instead returning to the expected Workspace list.
2. This issue does not occur when connecting to NetSuite, and others, where the navigation behaves as expected.

What is the root cause of that problem?

we pass the backTo route to it here:

App/src/pages/settings/Security/TwoFactorAuth/Steps/CodesStep.tsx

Line 64 in 5967584

onBackButtonPress={() => TwoFactorAuthActions.quitAndNavigateBack(backTo)}

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

We don't need to pass the backTo

App/src/pages/settings/Security/TwoFactorAuth/Steps/CodesStep.tsx

Line 64 in 5967584

onBackButtonPress={() => TwoFactorAuthActions.quitAndNavigateBack(backTo)}

just write:
onBackButtonPress={() => TwoFactorAuthActions.quitAndNavigateBack()}

this change solve the issue mentioned in the OP, and does not cause any regression for 2FA used in the Security page,.

How does the above change work when visiting 2FA page directly via URL - How is the accounting page added as the backTo in the navigation stack?

When we open the 2FA page directly through the URL with the backTo parameter, the app still knows where to go back because:

1. The URL's backTo parameter (settings/workspaces/{workspaceId}/accounting) is processed by getMatchingRootRouteForRHPRoute function, which:

   • Takes this URL and converts it to a navigation state using getStateFromPath(route.params.backTo, config)
   • Checks for the target screen type (RHP navigator, full screen navigator, or central pane screen)
   • In our case, it finds that the accounting page is FullScreenNavigator

2. The app then uses this information to set up the correct navigation stack, even though we didn't navigate there step by step. This happens in the getAdaptedState function, which:

   • Sets up the proper bottom tab navigator
   • Adds the matching central pane route (accounting page in our case)
   • Adds the RHP navigator (2FA screen)

So even when accessing the 2FA page directly, the backTo parameter helps the app reconstruct the proper navigation stack context. That's why when we click the back button (which calls navigation.goBack()), it knows to take us back to the accounting page.

We can actually verify this behavior by testing: if we remove the backTo parameter from the URL, the back navigation won't work as expected because the app won't have the information needed to reconstruct the proper navigation stack. This is because the logic in getMatchingRootRouteForRHPRoute specifically checks for and relies on this parameter:

if (route.params && 'backTo' in route.params && typeof route.params.backTo === 'string') {
    const stateForBackTo = getStateFromPath(route.params.backTo, config);
    if (stateForBackTo) {
        // If we know that backTo targets the root route (full screen) we want to use it.
            const fullScreenNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.FULL_SCREEN_NAVIGATOR);
            if (fullScreenNavigator && fullScreenNavigator.state) {
                return fullScreenNavigator as NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR>;
            }
    }
}

FullScreenNavigator will have settings/workspaces/{workspaceId}/accounting as path with it.

App/src/libs/Navigation/linkingConfig/getAdaptedStateFromPath.ts

Lines 127 to 131 in 608ec61

	// If we know that backTo targets the root route (full screen) we want to use it.
	const fullScreenNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.FULL_SCREEN_NAVIGATOR);
	if (fullScreenNavigator && fullScreenNavigator.state) {
	return fullScreenNavigator as NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR>;
	}

here is all the related code:

App/src/libs/Navigation/linkingConfig/getAdaptedStateFromPath.ts

Lines 116 to 126 in 608ec61

	function getMatchingRootRouteForRHPRoute(route: NavigationPartialRoute): NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR> | undefined {
	// Check for backTo param. One screen with different backTo value may need diferent screens visible under the overlay.
	if (route.params && 'backTo' in route.params && typeof route.params.backTo === 'string') {
	const stateForBackTo = getStateFromPath(route.params.backTo, config);
	if (stateForBackTo) {
	// If there is rhpNavigator in the state generated for backTo url, we want to get root route matching to this rhp screen.
	const rhpNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR);
	if (rhpNavigator && rhpNavigator.state) {
	return getMatchingRootRouteForRHPRoute(findFocusedRoute(stateForBackTo) as NavigationPartialRoute);
	}

Note: For better verification, we can add a breakpoint at getMatchingRootRouteForRHPRoute function and access the page with the direct URL (https://dev.new.expensify.com:8082/settings/security/two-factor-auth?backTo=settings%2Fworkspaces%2F{workspaceId}%2Faccounting&forwardTo=https%3A%2F%2Fwww.expensify.com%2Fapi%2FConnectPolicyToXero%3FpolicyID%3D{workspaceId}) - this will let us inspect exactly how the backTo parameter is being processed.

Screen.20Recording.202024-10-20.20at.2011.mp4

iOS

Screen.Recording.2024-10-14.at.12.26.00.AM.mov

[NJ-2020]

Proposal

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

Navigation issue when tapping app back button three times after exiting 2FA setup

What is the root cause of that problem?

When we press the go back button inside the TwoFactorAuth page, we invoke this function

App/src/libs/actions/TwoFactorAuthActions.ts

Lines 21 to 24 in 2329c78

	function quitAndNavigateBack(backTo?: Route) {
	clearTwoFactorAuthData();
	Navigation.goBack(backTo);
	}

We pass the fallback route which leads to this issue

App/src/libs/Navigation/Navigation.ts

Lines 201 to 205 in 2329c78

	* @param fallbackRoute - Fallback route if pop/goBack action should, but is not possible within RHP
	* @param shouldEnforceFallback - Enforces navigation to fallback route
	* @param shouldPopToTop - Should we navigate to LHN on back press
	*/
	function goBack(fallbackRoute?: Route, shouldEnforceFallback = false, shouldPopToTop = false) {

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

Remove the backTo(fallbackRoute)

What alternative solutions did you explore? (Optional)

[melvin-bot]

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

[melvin-bot]

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

[FitseTLT]

Edited by proposal-police: This proposal was edited at 2024-10-14 20:31:49 UTC.

Proposal

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

iOS Xero - Navigation issue when tapping app back button three times after exiting 2FA setup

What is the root cause of that problem?

When we press back button goBack is called with fallbackRoute

App/src/libs/actions/TwoFactorAuthActions.ts

Line 23 in 8ff185a

Navigation.goBack(backTo);

but because it is first route in the navigator it will navigate to the fallbackRoute here

App/src/libs/Navigation/Navigation.ts

Line 235 in 8ff185a

navigate(fallbackRoute, CONST.NAVIGATION.TYPE.UP);

which will replace the 2FA route with the accounting page. That will create a duplicate workspace accounting route to the navigation state.

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

Instead of navigating to the fallBackRoute here with Replace action we should goBack, which will play the role of REPLACE action we were using, and then navigate to the fallbackRoute

App/src/libs/Navigation/Navigation.ts

Line 235 in 8ff185a

navigate(fallbackRoute, CONST.NAVIGATION.TYPE.UP);

navigationRef.current.goBack();
        navigate(fallbackRoute);

This will create the same effect as the navigating with REPLACE and whenever the fallbackRoute is the same as the route we are going back to it will not create a duplicate route in the navigation state and instead leave it.

What alternative solutions did you explore? (Optional)

We can also avoid having backTo here

App/src/pages/settings/Security/TwoFactorAuth/Steps/CodesStep.tsx

Line 69 in 5103b4b

onBackButtonPress={() => TwoFactorAuthActions.quitAndNavigateBack(backTo)}

for the case of Xero so change it to

       onBackButtonPress={() =>
                TwoFactorAuthActions.quitAndNavigateBack(route.params.forwardTo && !route.params.forwardTo?.includes(READ_COMMANDS.CONNECT_POLICY_TO_XERO) ? backTo : '')
            }

because we navigate to ROUTES.SETTINGS_2FA from different flows we need it for other cases
This will work for direct link access too because whenever full screen navigator is found in the state found from backTo of the route we add the necessary full navigator here

App/src/libs/Navigation/linkingConfig/getAdaptedStateFromPath.ts

Lines 127 to 132 in 5103b4b

	// If we know that backTo targets the root route (full screen) we want to use it.
	const fullScreenNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.FULL_SCREEN_NAVIGATOR);
	if (fullScreenNavigator && fullScreenNavigator.state) {
	return fullScreenNavigator as NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR>;
	}

and as we will not remove the backTo from the route it will work perfect.

[hoangzinh]

Thanks for all your proposals.

• @Shahidullah-Muffakir @NJ-2020 I don't think your solution is correct. We need the fallback route, just in case we visit the 2FA page with a direct link.
• @FitseTLT, your solution works in this case but if we have the same situation on other pages in the workspace, it won't work.

Btw, I feel that we haven't dug deep enough the root cause yet

[twisterdotcom]

@Shahidullah-Muffakir, @NJ-2020 oe, @FitseTLT - do any of you want to take another stab at this or respond to @hoangzinh?

[Shahidullah-Muffakir]

@twisterdotcom @hoangzinh , I have updated my proposal #50695 (comment) , thank you.

[hoangzinh]

@Shahidullah-Muffakir, thank you for the updates. Your proposal still does not explain why passing backTo route caused the bug, also your proposed solution hasn't explained why removing backTo param will fix this issue. Besides that, can you explain why it won't cause a regression bug when we visit the direct link, for example, https://dev.new.expensify.com:8082/settings/security/two-factor-auth?backTo=settings%2Fworkspaces%2F{workspaceId}%2Faccounting&forwardTo=https%3A%2F%2Fwww.expensify.com%2Fapi%2FConnectPolicyToXero%3FpolicyID%3D{workspaceId} It will go back to the correct workspace's accounting page when we tap on the "Back" icon of 2FA page (on small screen devices).

[melvin-bot]

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

[FitseTLT]

@hoangzinh Updated
FYI: The updated solution will solve similar issues as #51107

[Shahidullah-Muffakir]

@Shahidullah-Muffakir, thank you for the updates. Your proposal still does not explain why passing backTo route caused the bug, also your proposed solution hasn't explained why removing backTo param will fix this issue. Besides that, can you explain why it won't cause a regression bug when we visit the direct link, for example, https://dev.new.expensify.com:8082/settings/security/two-factor-auth?backTo=settings%2Fworkspaces%2F{workspaceId}%2Faccounting&forwardTo=https%3A%2F%2Fwww.expensify.com%2Fapi%2FConnectPolicyToXero%3FpolicyID%3D{workspaceId} It will go back to the correct workspace's accounting page when we tap on the "Back" icon of 2FA page (on small screen devices).

@hoangzinh,Sorry for the delayed reply. I'm not 100% sure if my response will fully clarify things, but here's what I observed:
When we pass the backTo parameter in this line of code:

App/src/pages/settings/Security/TwoFactorAuth/Steps/CodesStep.tsx

Line 64 in 5967584

onBackButtonPress={() => TwoFactorAuthActions.quitAndNavigateBack(backTo)}

this triggers the following condition in the Navigation.goBack function:

App/src/libs/Navigation/Navigation.ts

Lines 234 to 237 in 65b739d

	if (shouldEnforceFallback || (isFirstRouteInNavigator && fallbackRoute)) {
	navigate(fallbackRoute, CONST.NAVIGATION.TYPE.UP);
	return;
	}

This seems to add the accounting page twice in the navigation stack, causing the issue where we keep getting stuck on that page.

However, when we remove the backTo parameter from this line:

App/src/pages/settings/Security/TwoFactorAuth/Steps/CodesStep.tsx

Line 64 in 5967584

onBackButtonPress={() => TwoFactorAuthActions.quitAndNavigateBack(backTo)}

the following line executes in Navigation.goBack:

App/src/libs/Navigation/Navigation.ts

Line 278 in 65b739d

navigationRef.current.goBack();

It seems that when we open the page via the direct URL, the backTo is in the URL, and the app correctly navigates back to the accounting page using navigationRef.current.goBack() without needing to explicitly pass the backTo parameter.
Thank you.

Attaching a screen recording of accessing the page directly via the URL in Mobile Safari

Screen.Recording.2024-10-23.at.2.35.03.AM.mov

[hoangzinh]

Thanks for updates @FitseTLT @Shahidullah-Muffakir I will manage to review both soon.

[hoangzinh]

which will play the role of REPLACE action we were using

@FitseTLT, Thanks for updates. Can you explain this a little bit? When did we use REPLACE option? Thanks.

[hoangzinh]

It seems that when we open the page via the direct URL, the backTo is in the URL, and the app correctly navigates back to the accounting page using navigationRef.current.goBack() without needing to explicitly pass the backTo parameter

@Shahidullah-Muffakir Thanks for updates. Yep, that is the thing we need to find out how this magic works. RCA needs to be clear to ensure we reach the root cause. Can you help to deep dive to understand your assumption here? "without needing to explicitly pass the backTo parameter" Thanks

[FitseTLT]

which will play the role of REPLACE action we were using

@FitseTLT, Thanks for updates. Can you explain this a little bit? When did we use REPLACE option? Thanks.

@hoangzinh when we navigate to it with type UP for a fallbackRoute case here

App/src/libs/Navigation/Navigation.ts

Lines 234 to 235 in f46bce0

	if (shouldEnforceFallback || (isFirstRouteInNavigator && fallbackRoute)) {
	navigate(fallbackRoute, CONST.NAVIGATION.TYPE.UP);

we will set the action to REPLACE here

App/src/libs/Navigation/linkTo/index.ts

Lines 114 to 115 in f46bce0

	if (type === CONST.NAVIGATION.TYPE.UP) {
	action.type = CONST.NAVIGATION.ACTION_TYPE.REPLACE;

therefore the nav action will replace the current route with the fallbackRoute as it doesn't know the route before that is the same as the fallbackRoute we will end up having duplicate routes in nav state.
So what we should do is goBack to remove the current route from the nav state and then navigate to the fallBackRoute in which case if the prevRoute is the same as the fallbackRoute it will leave it as it is and not create a duplicate route which will solve similar issues for the future too.

[melvin-bot]

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

[FitseTLT]

@hoangzinh I have updated to give an alternative approach of passing empty backTo (for 2FA page only for the case of Xero) as I have proposed initially along with the analysis for the reason it will work for deep link case 👍

[Shahidullah-Muffakir]

@hoangzinh , When we open the 2FA page directly through the URL with the backTo parameter, the app still knows where to go back because:

1. The URL's backTo parameter (settings/workspaces/{workspaceId}/accounting) is processed by getMatchingRootRouteForRHPRoute function, which:

   • Takes this URL and converts it to a navigation state using getStateFromPath(route.params.backTo, config)
   • Checks for the target screen type (RHP navigator, full screen navigator, or central pane screen)
   • In our case, it finds that the accounting page is FullScreenNavigator

2. The app then uses this information to set up the correct navigation stack, even though we didn't navigate there step by step. This happens in the getAdaptedState function, which:

   • Sets up the proper bottom tab navigator
   • Adds the matching central pane route (accounting page in our case)
   • Adds the RHP navigator (2FA screen)

So even when accessing the 2FA page directly, the backTo parameter helps the app reconstruct the proper navigation stack context. That's why when we click the back button (which calls navigation.goBack()), it knows to take us back to the accounting page.

We can actually verify this behavior by testing: if we remove the backTo parameter from the URL, the back navigation won't work as expected because the app won't have the information needed to reconstruct the proper navigation stack. This is because the logic in getMatchingRootRouteForRHPRoute specifically checks for and relies on this parameter:

if (route.params && 'backTo' in route.params && typeof route.params.backTo === 'string') {
    const stateForBackTo = getStateFromPath(route.params.backTo, config);
    if (stateForBackTo) {
        // If we know that backTo targets the root route (full screen) we want to use it.
            const fullScreenNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.FULL_SCREEN_NAVIGATOR);
            if (fullScreenNavigator && fullScreenNavigator.state) {
                return fullScreenNavigator as NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR>;
            }
    }
}

FullScreenNavigator will have settings/workspaces/{workspaceId}/accounting as path with it.

App/src/libs/Navigation/linkingConfig/getAdaptedStateFromPath.ts

Lines 127 to 131 in 608ec61

	// If we know that backTo targets the root route (full screen) we want to use it.
	const fullScreenNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.FULL_SCREEN_NAVIGATOR);
	if (fullScreenNavigator && fullScreenNavigator.state) {
	return fullScreenNavigator as NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR>;
	}

here is all the related code:

App/src/libs/Navigation/linkingConfig/getAdaptedStateFromPath.ts

Lines 116 to 126 in 608ec61

	function getMatchingRootRouteForRHPRoute(route: NavigationPartialRoute): NavigationPartialRoute<CentralPaneName | typeof NAVIGATORS.FULL_SCREEN_NAVIGATOR> | undefined {
	// Check for backTo param. One screen with different backTo value may need diferent screens visible under the overlay.
	if (route.params && 'backTo' in route.params && typeof route.params.backTo === 'string') {
	const stateForBackTo = getStateFromPath(route.params.backTo, config);
	if (stateForBackTo) {
	// If there is rhpNavigator in the state generated for backTo url, we want to get root route matching to this rhp screen.
	const rhpNavigator = stateForBackTo.routes.find((rt) => rt.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR);
	if (rhpNavigator && rhpNavigator.state) {
	return getMatchingRootRouteForRHPRoute(findFocusedRoute(stateForBackTo) as NavigationPartialRoute);
	}

Note: For better verification, we can add a breakpoint at getMatchingRootRouteForRHPRoute function and access the page with the direct URL (https://dev.new.expensify.com:8082/settings/security/two-factor-auth?backTo=settings%2Fworkspaces%2F{workspaceId}%2Faccounting&forwardTo=https%3A%2F%2Fwww.expensify.com%2Fapi%2FConnectPolicyToXero%3FpolicyID%3D{workspaceId}) - this will let us inspect exactly how the backTo parameter is being processed.

[hoangzinh]

@FitseTLT @Shahidullah-Muffakir Thanks for keeping us updated. I appreciate it.

After reviewing, testing both solutions and based on the suggestion here. I think @Shahidullah-Muffakir is good for now. Can you add what you found here in your proposal?

[FitseTLT]

@hoangzinh

1. What @Shahidullah-Muffakir found here [HOLD for payment 2024-11-22] [$250] iOS Xero - Navigation issue when tapping app back button three times after exiting 2FA setup #50695 (comment) is hours after I updated the proposal to include the exact analysis and you were asking him even before 5 days here but wasn't able to provide
2. We cannot just leave the backTo because we will need it here so we should make an exception for Xero flow as I have suggested in my alternative solution. Please note that 2FA page is not only used here in Xero flow. Thx. 👍

[Shahidullah-Muffakir]

@hoangzinh updated my Proposal, Thank you.

[hoangzinh]

@FitseTLT Oh wait, you're right. @Shahidullah-Muffakir's solution will cause a regression bug in the Reimbursement flow

Screen.Recording.2024-10-30.at.05.28.29.mov

[Shahidullah-Muffakir]

@FitseTLT Oh wait, you're right. @Shahidullah-Muffakir's solution will cause a regression bug in the Reimbursement flow

Screen.Recording.2024-10-30.at.05.28.29.mov

@FitseTLT is correct - while I only tested the regression on the Security page navigation, I missed testing the Reimbursement flow mentioned. Thank you.

[hoangzinh]

Cool. Thanks to everyone for putting your effort into finding a root cause and a good solution for now. We can go with the alternative solution of @FitseTLT

Link to proposal #50695 (comment)

🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @stitesExpensify, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[melvin-bot]

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

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

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

• Fix - iOS Xero - Navigation issue when tapping app back button three times after exiting 2FA setup #51817

If no regressions arise, payment will be issued on 2024-11-22. 🎊

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

• @hoangzinh requires payment through NewDot Manual Requests
• @FitseTLT requires payment automatic offer (Contributor)

[melvin-bot]

@hoangzinh @twisterdotcom @hoangzinh The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]