[$250] Android - Expense - Device back button on track distance screen lead to previous tab instead of closing it

[applause-bot]

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.4.22-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93268
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Money Requests

Action Performed:

1. Open the Expensify app.
2. Tap on FAB > "Track Distance"
3. Switch to a tab different than the one opened. (Map/Manual/GPS/Odometer)
4. Use device´s back button.
5. Note that you are returned to previous tab instead of returning to chats list.

Expected Result:

Using device´s back button during track distance expense creation flow, should close the creation screen and return to chats list.

Actual Result:

Using device´s back button during track distance expense creation, leads to previous tab instead of closing creation screen and returning to chats list.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7194303_1782740121633.Modal_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7194303

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071608987595556902
• Upwork Job ID: 2071608987595556902
• Last Price Increase: 2026-06-29

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/10b0dc6e153a69d37199747a8ba57b50a072356191f1ddafd0751f40f3605549

[MelvinBot]

Proposal

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

On Android (native), pressing the device back button in the Track Distance creation flow returns to the previously-selected tab (Map/Manual/GPS/Odometer) instead of closing the creation screen and returning to the chats list.

What is the root cause of that problem?

The distance tabs are rendered by an OnyxTabNavigator (a real createMaterialTopTabNavigator), and on native its backBehavior is 'initialRoute'. After a tab switch, react-navigation's TabRouter holds a 2-entry tab history [initialTab, currentTab], so the hardware back is consumed by the container's back handler (canGoBack() is true) and resolved into a GO_BACK that pops back to the initial tab — it never bubbles up to the RHP stack that would close the flow.

Critically, DistanceRequestStartPage.tsx never installs a page-level useAndroidBackButtonHandler — unlike IOURequestStartPage.tsx:209-214, which does. The BackHandler added in PR #93268 (via useDiscardChangesConfirmation) only intercepts the back when the form is dirty; with a clean form it returns false and the tab GO_BACK runs.

Evidence & data flow

• Native backBehavior is 'initialRoute': OnyxTabNavigatorConfig/index.ts:8 (web uses 'none', which is why the browser back correctly leaves the flow — the two platforms diverge here).
• Tab navigator: OnyxTabNavigator.tsx:60-169.
• Dirty-only interception: useDiscardChangesConfirmation/index.native.ts:78-92 returns false when there are no unsaved changes.

Flow (clean form, Android): open Track Distance (Map tab) → tap Manual (TabRouter history [Map, Manual]) → press device back → useDiscardChangesConfirmation handler returns false (not dirty) → container useBackButton sees canGoBack() true → GO_BACK → TabRouter pops to Map and consumes the action → RHP never closes. Bug.

Regression note: the native GO_BACK → initial-tab mechanic pre-dates #93268 (that PR only relocated the backBehavior literal and did not touch DistanceRequestStartPage.tsx or useAndroidBackButtonHandler). #93268 fixed the dirty path (discard modal then close) but the clean path still falls through. The underlying gap — the distance start page lacking a page-level back handler like IOURequestStartPage — is pre-existing.

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

Mirror what IOURequestStartPage.tsx already does. In src/pages/iou/request/DistanceRequestStartPage.tsx:

• Add import useAndroidBackButtonHandler from '@hooks/useAndroidBackButtonHandler';
• After navigateBack, register a handler:

  const onBackButtonPress = () => {
      navigateBack();
      return true;
  };
  useAndroidBackButtonHandler(onBackButtonPress);

This installs a focus-scoped Android BackHandler that returns true and calls closeRHPFlow(), intercepting the hardware back before react-navigation converts it into a tab GO_BACK.

To verify during implementation: BackHandler runs listeners newest-first. The per-tab useDiscardChangesConfirmation handler (registered when the focused child mounts) must still win for dirty forms so the discard modal shows; the page-level handler should only catch the clean case. Confirm this ordering on-device. Also check whether the edit flow (IOURequestStepDistance.tsx, DISTANCE_MAP/DISTANCE_MANUAL tabs) needs the same treatment.

Related issues

• [Odometer] Show discard changes modal when switching tabs with unsaved values #89940 — discard-changes modal on tab switch (Odometer); same useDiscardChangesConfirmation area.
• [Exploratory] 92988-iOS-Track Distance-Navigate to confirmation page after tracking distance and swipe back #93069 — Track Distance swipe-back exploratory; adjacent navigation behavior.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94863) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The Track Distance creation screen renders its tabs (Map/Manual/GPS/Odometer) inside an OnyxTabNavigator (a material top-tab navigator) in DistanceRequestStartPage:

App/src/pages/iou/request/DistanceRequestStartPage.tsx

Lines 123 to 172 in 05d32d5

	<OnyxTabNavigator
	id={CONST.TAB.DISTANCE_REQUEST_TYPE}
	defaultSelectedTab={defaultSelectedTab}
	onTabSelected={resetIOUTypeIfChanged}
	tabBar={TabSelector}
	onTabBarFocusTrapContainerElementChanged={setTabBarContainerElement}
	onActiveTabFocusTrapContainerElementChanged={setActiveTabContainerElement}
	lazyLoadEnabled
	>
	<TopTab.Screen name={CONST.TAB_REQUEST.DISTANCE_MAP}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<IOURequestStepDistanceMap
	route={route}
	navigation={navigation}
	/>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	<TopTab.Screen name={CONST.TAB_REQUEST.DISTANCE_MANUAL}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<IOURequestStepDistanceManual
	route={route}
	navigation={navigation}
	/>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	<TopTab.Screen name={CONST.TAB_REQUEST.DISTANCE_GPS}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<IOURequestStepDistanceGPS
	route={route}
	navigation={navigation}
	/>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	<TopTab.Screen name={CONST.TAB_REQUEST.DISTANCE_ODOMETER}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<IOURequestStepDistanceOdometer
	route={route}
	navigation={navigation}
	/>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	</OnyxTabNavigator>

On Android, the device hardware back button is handled by React Navigation. When a top-tab navigator has tab-focus history (i.e. the user switched away from the first tab), the navigator's default hardwareBackPress behavior is to navigate back to the previously focused tab rather than dismissing the screen. DistanceRequestStartPage only wires the header back button to close the flow — it never registers a hardware-back handler:

App/src/pages/iou/request/DistanceRequestStartPage.tsx

Lines 88 to 121 in 05d32d5

	const navigateBack = () => {
	Navigation.closeRHPFlow();
	};
	const [headerWithBackBtnContainerElement, setHeaderWithBackButtonContainerElement] = useState<HTMLElement | null>(null);
	const [tabBarContainerElement, setTabBarContainerElement] = useState<HTMLElement | null>(null);
	const [activeTabContainerElement, setActiveTabContainerElement] = useState<HTMLElement | null>(null);
	const focusTrapContainerElements = useMemo(() => {
	return [headerWithBackBtnContainerElement, tabBarContainerElement, activeTabContainerElement].filter((element) => !!element);
	}, [headerWithBackBtnContainerElement, tabBarContainerElement, activeTabContainerElement]);
	return (
	<AccessOrNotFoundWrapper
	reportID={reportID}
	iouType={iouType}
	policyID={policy?.id}
	accessVariants={[CONST.IOU.ACCESS_VARIANTS.CREATE]}
	>
	<ScreenWrapper
	shouldEnableKeyboardAvoidingView={selectedTab === CONST.TAB_REQUEST.DISTANCE_ODOMETER}
	shouldEnableMinHeight={canUseTouchScreen()}
	testID="DistanceRequestStartPage"
	focusTrapSettings={{containerElements: focusTrapContainerElements}}
	>
	<View style={styles.flex1}>
	<FocusTrapContainerElement
	onContainerElementChanged={setHeaderWithBackButtonContainerElement}
	style={[styles.w100]}
	>
	<HeaderWithBackButton
	title={tabTitles[iouType]}
	onBackButtonPress={navigateBack}
	/>

So the header's onBackButtonPress={navigateBack} (Navigation.closeRHPFlow()) is bypassed entirely when the user presses the device back button — the tab navigator consumes the event first and just restores the previous tab.

Contrast this with the regular create page IOURequestStartPage, which renders the same kind of OnyxTabNavigator but additionally intercepts the Android hardware back button and routes it through navigateBack, returning true so the navigator's default tab-back behavior never runs:

App/src/pages/iou/request/IOURequestStartPage.tsx

Lines 209 to 214 in 05d32d5

	const onBackButtonPress = () => {
	navigateBack();
	return true;
	};
	useAndroidBackButtonHandler(onBackButtonPress);

This is a regression introduced when the distance flow was split into its own dedicated DistanceRequestStartPage in #91943 (the file's first commit cd24efdd821) — the new page copied the header/tab structure from IOURequestStartPage but did not carry over its useAndroidBackButtonHandler call.

So: device back pressed on a non-first distance tab → top-tab navigator consumes hardwareBackPress and pops tab-focus history → navigateBack/closeRHPFlow is never reached → user lands on the previous tab instead of the chats list. (Android-only, because useAndroidBackButtonHandler is a no-op on web/iOS — consistent with the "Android: App only" platform checkbox.)

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

Reuse the exact same handler IOURequestStartPage already uses — useAndroidBackButtonHandler (src/hooks/useAndroidBackButtonHandler, already in scope across the codebase). Add the import and register a handler in DistanceRequestStartPage that consumes the event and closes the flow, mirroring IOURequestStartPage L209-L214:

+ import useAndroidBackButtonHandler from '@hooks/useAndroidBackButtonHandler';

  const navigateBack = () => {
      Navigation.closeRHPFlow();
  };
+
+ const onBackButtonPress = () => {
+     navigateBack();
+     return true;
+ };
+
+ useAndroidBackButtonHandler(onBackButtonPress);

Returning true tells BackHandler the press was handled, so React Navigation's default tab-back behavior is suppressed and closeRHPFlow() runs instead — returning the user to the chats list from any tab, exactly as the header back button already does. The hook is a no-op on web/iOS, so there is zero risk to those platforms.

Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Resetting the tab-focus history or disabling the navigator's back behavior via navigation options. This is heavier, navigator-internal, and would still not converge the device back button onto the existing navigateBack logic. Reusing useAndroidBackButtonHandler is the smallest, regression-free fix and keeps DistanceRequestStartPage consistent with the sibling IOURequestStartPage.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The distance expense create screen is implemented as nested top tabs for Map, Manual, GPS, and Odometer, and those tabs are deep-linked as children of SCREENS.MONEY_REQUEST.DISTANCE_CREATE.

App/src/pages/iou/request/DistanceRequestStartPage.tsx

Lines 123 to 172 in bda115b

	<OnyxTabNavigator
	id={CONST.TAB.DISTANCE_REQUEST_TYPE}
	defaultSelectedTab={defaultSelectedTab}
	onTabSelected={resetIOUTypeIfChanged}
	tabBar={TabSelector}
	onTabBarFocusTrapContainerElementChanged={setTabBarContainerElement}
	onActiveTabFocusTrapContainerElementChanged={setActiveTabContainerElement}
	lazyLoadEnabled
	>
	<TopTab.Screen name={CONST.TAB_REQUEST.DISTANCE_MAP}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<IOURequestStepDistanceMap
	route={route}
	navigation={navigation}
	/>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	<TopTab.Screen name={CONST.TAB_REQUEST.DISTANCE_MANUAL}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<IOURequestStepDistanceManual
	route={route}
	navigation={navigation}
	/>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	<TopTab.Screen name={CONST.TAB_REQUEST.DISTANCE_GPS}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<IOURequestStepDistanceGPS
	route={route}
	navigation={navigation}
	/>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	<TopTab.Screen name={CONST.TAB_REQUEST.DISTANCE_ODOMETER}>
	{() => (
	<TabScreenWithFocusTrapWrapper>
	<IOURequestStepDistanceOdometer
	route={route}
	navigation={navigation}
	/>
	</TabScreenWithFocusTrapWrapper>
	)}
	</TopTab.Screen>
	</OnyxTabNavigator>

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

Lines 1702 to 1722 in bda115b

	[SCREENS.MONEY_REQUEST.DISTANCE_CREATE]: {
	path: ROUTES.DISTANCE_REQUEST_CREATE.route,
	exact: true,
	screens: {
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'distance-map': {
	path: ROUTES.DISTANCE_REQUEST_CREATE_TAB_MAP.route,
	},
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'distance-manual': {
	path: ROUTES.DISTANCE_REQUEST_CREATE_TAB_MANUAL.route,
	},
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'distance-gps': {
	path: ROUTES.DISTANCE_REQUEST_CREATE_TAB_GPS.route,
	},
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'distance-odometer': {
	path: ROUTES.DISTANCE_REQUEST_CREATE_TAB_ODOMETER.route,
	},
	},

On native, OnyxTabNavigator always passes the shared backBehavior to TopTab.Navigator, and that shared native value is initialRoute. Because the distance flow does not override it, Android hardware back is handled by the top-tab navigator first and returns to the initial Map tab instead of letting the parent RHP flow close.

App/src/libs/Navigation/OnyxTabNavigator.tsx

Lines 165 to 170 in bda115b

	<TopTab.Navigator
	{...rest}
	id={id}
	initialRouteName={validInitialTab}
	backBehavior={backBehavior}
	keyboardDismissMode="none"

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

Lines 7 to 8 in bda115b

	/** On native there is no browser history; hardware back returns to the initial tab first, per platform convention. */
	const backBehavior: NonNullable<TabRouterOptions['backBehavior']> = 'initialRoute';

This is why the header back button behaves correctly, since it already calls Navigation.closeRHPFlow(), while the device back button is intercepted by tab back behavior before the flow can close.

App/src/pages/iou/request/DistanceRequestStartPage.tsx

Lines 88 to 90 in bda115b

	const navigateBack = () => {
	Navigation.closeRHPFlow();
	};

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

Allow OnyxTabNavigator to accept an optional backBehavior prop, defaulting to the existing imported shared value so all current call sites keep their behavior. Because the component currently spreads ...rest before assigning backBehavior, this needs to be an explicit prop rather than relying on rest props.

App/src/libs/Navigation/OnyxTabNavigator.tsx

Lines 163 to 170 in bda115b

	return (
	<TabFocusTrapContext.Provider value={setTabFocusTrapContainerElement}>
	<TopTab.Navigator
	{...rest}
	id={id}
	initialRouteName={validInitialTab}
	backBehavior={backBehavior}
	keyboardDismissMode="none"

Then pass backBehavior="none" from DistanceRequestStartPage only. With none, tab switches still update the selected distance tab, but the top-tab navigator does not consume Android hardware back to navigate between distance tabs. The back action can then bubble to the parent modal/RHP navigation and close the distance creation flow, matching the existing header back behavior.

App/src/pages/iou/request/DistanceRequestStartPage.tsx

Lines 123 to 130 in bda115b

	<OnyxTabNavigator
	id={CONST.TAB.DISTANCE_REQUEST_TYPE}
	defaultSelectedTab={defaultSelectedTab}
	onTabSelected={resetIOUTypeIfChanged}
	tabBar={TabSelector}
	onTabBarFocusTrapContainerElementChanged={setTabBarContainerElement}
	onActiveTabFocusTrapContainerElementChanged={setActiveTabContainerElement}
	lazyLoadEnabled

Test coverage:

• Add/update a navigation unit test for OnyxTabNavigator or the distance create route state that verifies the distance create tab navigator can be configured with backBehavior="none" while the default remains unchanged.
• Manually verify on Android: FAB > Track Distance, switch from Map to Manual/GPS/Odometer, press the device back button, and confirm the flow closes to the chats list instead of returning to Map.
• Regression-check that tapping the in-app back button on the same screen still closes the flow.

What alternative solutions did you explore? (Optional)

Adding a hardware BackHandler in DistanceRequestStartPage would also close the flow, but it would duplicate navigation behavior outside React Navigation and risk conflicting with nested pages such as odometer image capture. A scoped backBehavior="none" keeps the behavior declarative at the navigator level.

[lorretheboy]

Proposal

What is the root cause of that problem?

The Track Distance create flow renders its Map/Manual/GPS/Odometer tabs inside an OnyxTabNavigator, and on native that navigator uses backBehavior: 'initialRoute':

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

Lines 7 to 8 in d516575

	/** On native there is no browser history; hardware back returns to the initial tab first, per platform convention. */
	const backBehavior: NonNullable<TabRouterOptions['backBehavior']> = 'initialRoute';

When you switch to a non-initial tab and press the hardware back button, the native BackHandler added by useDiscardChangesConfirmation runs first. If there are no unsaved changes it returns false and lets react-navigation handle the press:

App/src/hooks/useDiscardChangesConfirmation/index.native.ts

Lines 80 to 92 in d516575

	useFocusEffect(() => {
	const subscription = BackHandler.addEventListener('hardwareBackPress', () => {
	if (isDiscardModalOpen.current) {
	return true;
	}
	if (!hasUnsavedChanges()) {
	return false;
	}
	showDiscardModal();
	return true;
	});
	return () => subscription.remove();
	});

react-navigation then routes the GO_BACK to the TabRouter, and because backBehavior is 'initialRoute' the TabRouter consumes it by switching back to the Map tab instead of letting it propagate up to dismiss the RHP. So you land on the previous tab rather than the chats list.

This is the native half of PR #93268 left unfinished: for web that PR made tab switches history-inert (backBehavior: 'none') precisely so back leaves the whole flow, but native kept 'initialRoute':

App/src/libs/Navigation/OnyxTabNavigatorConfig/index.web.ts

Lines 7 to 11 in d516575

	/**
	* `none` keeps the tab history at a single entry, so `useLinking` replaces the browser entry instead of
	* pushing one — tab switches add no history and the browser back button leaves the whole flow.
	*/
	const backBehavior: NonNullable<TabRouterOptions['backBehavior']> = 'none';

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

Mirror the web behavior on native: change backBehavior to 'none' in the native config so the TabRouter no longer swallows the back press.

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

Line 8 in d516575

const backBehavior: NonNullable<TabRouterOptions['backBehavior']> = 'initialRoute';

With 'none', a hardware back from any tab propagates to the parent stack and dismisses the RHP (returning to chats), regardless of which tab is active. The discard BackHandler still intercepts first when there are unsaved changes, so the confirmation modal continues to work.

What alternative solutions did you explore? (Optional)

Keep backBehavior: 'initialRoute' and instead make the native hook's no-unsaved-changes branch dismiss the flow itself (e.g. dispatch a root goBack instead of returning false). This is more targeted to the distance flow but useDiscardChangesConfirmation is shared with non-tab screens (Merchant, Description, Amount, etc.) where returning false is the correct behavior, so it would need to detect the tab context — more fragile than aligning the native config with web.

[dilshodmackbook-sketch]

Proposal

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

On Android, in the Track Distance creation flow, switching to a tab other than the default Map tab (Manual/GPS/Odometer) and then pressing the device hardware back button returns to the Map tab instead of closing the creation screen and returning to the chats list.

What is the root cause of that problem?

The Track Distance tabs are rendered by OnyxTabNavigator inside DistanceRequestStartPage:

App/src/pages/iou/request/DistanceRequestStartPage.tsx

Lines 123 to 131 in 62df01f

	<OnyxTabNavigator
	id={CONST.TAB.DISTANCE_REQUEST_TYPE}
	defaultSelectedTab={defaultSelectedTab}
	onTabSelected={resetIOUTypeIfChanged}
	tabBar={TabSelector}
	onTabBarFocusTrapContainerElementChanged={setTabBarContainerElement}
	onActiveTabFocusTrapContainerElementChanged={setActiveTabContainerElement}
	lazyLoadEnabled
	>

OnyxTabNavigator hardcodes backBehavior="initialRoute" for every consumer, on every platform — it is a literal in the component, not a value coming from OnyxTabNavigatorConfig:

App/src/libs/Navigation/OnyxTabNavigator.tsx

Lines 165 to 170 in 62df01f

	<TopTab.Navigator
	{...rest}
	id={id}
	initialRouteName={validInitialTab}
	backBehavior="initialRoute"
	keyboardDismissMode="none"

It's worth being precise here, because the platform-specific OnyxTabNavigatorConfig only differs by the animation screen option ('default' on native vs 'none' on web) — it does not carry backBehavior, so there is no native-vs-web back-behavior split to align:

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

Lines 1 to 3 in 62df01f

	const defaultScreenOptions = {
	animation: 'default',
	} as const;

With backBehavior="initialRoute", the Android hardware back is dispatched as a GO_BACK that the nested TabRouter resolves internally by switching to the initial Map tab and consuming the action, so it never propagates to the parent RHP stack that would close the flow. The header back button is unaffected because it bypasses the tab navigator and calls Navigation.closeRHPFlow() directly:

App/src/pages/iou/request/DistanceRequestStartPage.tsx

Lines 88 to 90 in 62df01f

	const navigateBack = () => {
	Navigation.closeRHPFlow();
	};

Two clarifications about why nothing else intercepts the press:

• DistanceRequestStartPage never registers a page-level Android back handler, unlike the sibling IOURequestStartPage, which routes hardware back through navigateBack and returns true:

  App/src/pages/iou/request/IOURequestStartPage.tsx

  Lines 204 to 209 in 62df01f

  	const onBackButtonPress = () => {
  	navigateBack();
  	return true;
  	};
  	useAndroidBackButtonHandler(onBackButtonPress);

• The discard-changes guard is present on the Odometer tab only (not Map/Manual/GPS), and it is built on React Navigation's usePreventRemove (the beforeRemove action event), not a raw hardwareBackPress BackHandler:

  App/src/hooks/useDiscardChangesConfirmation/index.native.ts

  Lines 18 to 26 in 62df01f

  	usePreventRemove(
  	shouldPrevent,
  	useCallback(
  	({data}: {data: {action: NavigationAction}}) => {
  	if (!getHasUnsavedChanges()) {
  	setShouldAllowNavigation(true);
  	navigationRef.current?.dispatch(data.action);
  	return;

  . beforeRemove only fires when a route is actually being removed; the tab GO_BACK above is consumed by the TabRouter and never removes the screen, so this guard is never reached on the clean back press regardless of the active tab.

So: device back on a non-Map tab → TabRouter consumes GO_BACK and switches to Map → closeRHPFlow() is never reached. Android-only, matching the platform checkbox.

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

Since backBehavior is hardcoded for all consumers, the scoped fix is to let OnyxTabNavigator accept an optional backBehavior prop that defaults to the current value, then opt the distance flow into "none".

In OnyxTabNavigator, add the prop with the existing default and pass it explicitly (it must be set explicitly rather than via ...rest, because the JSX currently assigns backBehavior after spreading rest):

function OnyxTabNavigator({
    // ...existing props
    backBehavior = 'initialRoute',
    ...rest
}) {
    // ...
    <TopTab.Navigator
        {...rest}
        id={id}
        initialRouteName={validInitialTab}
        backBehavior={backBehavior}
        // ...
    >
}

Then in DistanceRequestStartPage, pass backBehavior="none" to the navigator. With "none", the TabRouter declines to handle GO_BACK, so the press bubbles to the parent RHP stack and dismisses the flow from any tab — matching the header back button. Every other OnyxTabNavigator call site keeps "initialRoute", and web/iOS are unaffected.

What alternative solutions did you explore? (Optional)

Add a page-level useAndroidBackButtonHandler in DistanceRequestStartPage (the same hook IOURequestStartPage uses) that calls navigateBack and returns true. That also fixes it, but it intercepts the press imperatively with a second BackHandler outside React Navigation, which has to coexist with the Odometer tab's usePreventRemove guard. Scoping backBehavior="none" to this one navigator keeps the fix declarative and inside React Navigation, so the existing discard-confirmation flow on the Odometer tab continues to work unchanged. Changing the hardcoded backBehavior globally was rejected because it would alter back behavior for every tabbed screen (and on web too).

[melvin-bot]

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