[HOLD for payment 2024-11-11 - Waiting on checklist] [$250] Android – Sign in – Able to dismiss the Onboarding modal using back button

[IuliiaHerets]

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.44-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5043083
Email or phone of affected tester (no customers): ponikarchuks+1331024@gmail.com
Issue reported by: Applause Internal Team

Action Performed:

1. Go to staging app
2. Log in with a new Gmail account
3. When Onboarding modal appears tap on Something else
4. Background the app
5. Open app and tap back button some times

Expected Result:

Onboarding modal present

Actual Result:

Onboarding modal disappears

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6623468_1727975678459.And_signin.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021844399665498037051
• Upwork Job ID: 1844399665498037051
• Last Price Increase: 2024-10-17
• Automatic offers:
• suneox | Reviewer | 104560308

Issue Owner

Current Issue Owner: @suneox

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

@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

[layacat]

Proposal

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

Android – Sign in – Able to dismiss the Onboarding modal using back button

What is the root cause of that problem?

We didn't prevent pressing Back button on native platform for OnboardingPersonalDetails screen, so user still able to press back and move to previous screen (home screen).

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

Using the similar approach with OnboardingPurpose screen. We should implement BackHandler for the native platform of OnboardingPersonalDetails and prevent user going back when it's OnboardingPersonalDetails and the ONBOARDING_MODAL_NAVIGATOR stack length is 1 (So it's when OnboardingPersonalDetails is the only stack in the stack).

// OnboardingPersonalDetails/index.native.tsx
 const currentRoute: NavigationPartialRoute | undefined = navigationRef.getCurrentRoute();
 const rootState = navigationRef.getRootState();
 const onboardingNavigatorStackLength = adaptedState.routes.filter(
        (route) => route.name === NAVIGATORS.ONBOARDING_MODAL_NAVIGATOR,
    ).length

    useFocusEffect(
        useCallback(() => {
            // Return true to indicate that the back button press is handled here
            const backAction = () => {
                if (currentRoute?.name === SCREENS.ONBOARDING.PERSONAL_DETAILS && onboardingNavigatorStackLength === 1) {
                    return true;
                }
                return false;
            };

            const backHandler = BackHandler.addEventListener('hardwareBackPress', backAction);

            return () => backHandler.remove();
        }, [currentRoute?.name]),
    );

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[bernhardoj]

Edited by proposal-police: This proposal was edited at 2024-10-04 05:42:22 UTC.

Proposal

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

User is able to dismiss the onboarding flow on the personal details step.

What is the root cause of that problem?

The onboarding has 3 steps, purpose, work information, and personal details. On the purpose page, we already override the back button to prevent the user from going back.

App/src/pages/OnboardingPurpose/index.native.tsx

Lines 8 to 18 in 0ed41d7

	// To block android native back button behavior
	useFocusEffect(
	useCallback(() => {
	// Return true to indicate that the back button press is handled here
	const backAction = () => true;
	const backHandler = BackHandler.addEventListener('hardwareBackPress', backAction);
	return () => backHandler.remove();
	}, []),
	);

But this isn't present in either work information or personal details. However, that's not the problem. When going back from the work information or personal details, the user should be going back to the correct step instead of preventing them from going back.

What happens in this issue is, that when we reopen the app, the app will show the last step of the onboarding step, in our case, the personal details step.

App/src/libs/actions/Welcome/OnboardingFlow.ts

Lines 106 to 113 in 0ed41d7

	function startOnboardingFlow() {
	const currentRoute = navigationRef.getCurrentRoute();
	const {adaptedState} = getAdaptedStateFromPath(getOnboardingInitialPath(), linkingConfig.config, false);
	const focusedRoute = findFocusedRoute(adaptedState as PartialState<NavigationState<RootStackParamList>>);
	if (focusedRoute?.name === currentRoute?.name) {
	return;
	}
	navigationRef.resetRoot(adaptedState);

That's possible because of getAdaptedStateFromPath. The result from getAdaptedStateFromPath looks like this (simplified):

{
    routes: [{name: BottomTabNavigator}, {name: OnboardingModalNavigator, state: {routes: [{name: Onboarding_Personal_Details}]}}]
}

So, in the nav stack, only the onboarding personal details page is present. So, when going back, instead of going back to the purpose step, the page is closed.

Why this doesn't happen when we press go back using the in-app back button? That's because we reset the root state which contains the correct state for the onboarding navigator.

App/src/libs/actions/Welcome/OnboardingFlow.ts

Lines 140 to 145 in 0ed41d7

	function goBack() {
	adaptOnboardingRouteState();
	Navigation.isNavigationReady().then(() => {
	Navigation.goBack();
	});
	}

App/src/libs/actions/Welcome/OnboardingFlow.ts

Lines 52 to 101 in e4969b2

	function adaptOnboardingRouteState() {
	const currentRoute: NavigationPartialRoute | undefined = navigationRef.getCurrentRoute();
	if (!currentRoute || currentRoute?.name === SCREENS.ONBOARDING.PURPOSE) {
	return;
	}
	const rootState = navigationRef.getRootState();
	const adaptedState = rootState;
	const lastRouteIndex = (adaptedState?.routes?.length ?? 0) - 1;
	const onBoardingModalNavigatorState = adaptedState?.routes.at(lastRouteIndex)?.state;
	if (!onBoardingModalNavigatorState || onBoardingModalNavigatorState?.routes?.length > 1 || lastRouteIndex === -1) {
	return;
	}
	let adaptedOnboardingModalNavigatorState = {} as Readonly<PartialState<NavigationState>>;
	if (currentRoute?.name === SCREENS.ONBOARDING.ACCOUNTING && selectedPurpose === CONST.ONBOARDING_CHOICES.MANAGE_TEAM) {
	adaptedOnboardingModalNavigatorState = {
	index: 2,
	routes: [
	{
	name: SCREENS.ONBOARDING.PURPOSE,
	params: currentRoute?.params,
	},
	{
	name: SCREENS.ONBOARDING.EMPLOYEES,
	params: currentRoute?.params,
	},
	{...currentRoute},
	],
	} as Readonly<PartialState<NavigationState>>;
	} else {
	adaptedOnboardingModalNavigatorState = {
	index: 1,
	routes: [
	{
	name: SCREENS.ONBOARDING.PURPOSE,
	params: currentRoute?.params,
	},
	{...currentRoute},
	],
	} as Readonly<PartialState<NavigationState>>;
	}
	const route = adaptedState.routes.at(lastRouteIndex);
	if (route) {
	route.state = adaptedOnboardingModalNavigatorState;
	}
	navigationRef.resetRoot(adaptedState);
	}

But this solution will cause a brief LHN to be seen.

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

We should improve getAdaptedStateFromPath so that it returns the complete state for the onboarding navigator, then, we won't need adaptOnboardingRouteState anymore. The improvement will be inspired from adaptOnboardingRouteState logic to build the correct routes.

First, create a new function in a separate file called getOnboardingAdaptedState.

export default function getOnboardingAdaptedState(state: PartialState<NavigationState>): PartialState<NavigationState> {
    const onboardingRoute = state.routes[0];
    if (onboardingRoute.name === SCREENS.ONBOARDING.PURPOSE) {
        return state;
    }

    const routes = [];
    if (onboardingRoute.name === SCREENS.ONBOARDING.ACCOUNTING) {
        routes.push({name: SCREENS.ONBOARDING.PURPOSE});
        routes.push({name: SCREENS.ONBOARDING.EMPLOYEES});
        routes.push(onboardingRoute);
    } else {
        routes.push({name: SCREENS.ONBOARDING.PURPOSE});
        routes.push(onboardingRoute);
    }

    return {
        routes,
        index: routes.length - 1,
    }
}

Next, modify the onboarding navigator state here to use the new state from getOnboardingAdaptedState.

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

Lines 255 to 257 in 0ed41d7

	if (onboardingModalNavigator) {
	routes.push(onboardingModalNavigator);
	}

if (onboardingModalNavigator) {
    if (onboardingModalNavigator.state) {
        routes.push({
            ...onboardingModalNavigator,
            state: getOnboardingAdaptedState(onboardingModalNavigator.state),
        });
    } else {
        routes.push(onboardingModalNavigator);
    }
}

Last, we can remove OnboardingFlow.goBack and just use Navigation.goBack.

[allgandalf]

@blazejkustra we fixed this one right!!!!!!!!!!!!!!!!!!!!!!!!!!!! 😮

[twisterdotcom]

Sorry, should this be closed or are you saying it's a regression @allgandalf?

[twisterdotcom]

@allgandalf / @blazejkustra I can recreate this, so I'm going to make it external... but let me know if you think this should be handled by somebody specific.