[$250] iOS-Expense-"Track distance" screen briefly appears after swiping back

[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: v9.4.23-0
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): agexptest+pr290626@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 13 Mini/ iOS 26.5
App Component: Money Requests

Action Performed:

1. Open the Expensify app
2. Tap the FAB button > Track distance
3. Tap Odometer
4. Swipe back

Expected Result:

The Inbox or previous screen is displayed, and the "Track distance" screen does not appear or blink.

Actual Result:

The "Track distance" screen briefly appears after swiping back.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

0-02-01-9bcac2d7bbed103d734d15d1db07c184212dcde0f2990e07712feda8d0a81602_d6fd029aefb07d9.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7194740

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071697830269476015
• Upwork Job ID: 2071697830269476015
• Last Price Increase: 2026-07-13

Issue Owner

Current Issue Owner: @MobileMage

[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/8ebd3512fca7196ac309f79e3e609843000938fdd656e77f9bcdd6b1c846941f

[MelvinBot]

Proposal

⚠️ Auto-generated analysis. Confidence: medium-high (root cause is code-backed; the exact frame timing of the flash is best confirmed on an iOS device).

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

On iOS native, opening Track distance → tapping the Odometer tab → swiping back briefly flashes the Track distance screen before returning to the previous screen. Swiping back from a non-first tab should dismiss the whole screen cleanly with no blink.

What is the root cause of that problem?

"Track distance" is a single RHP screen hosting a 4-tab navigator (Map / Manual / GPS / Odometer) via OnyxTabNavigator. That navigator is configured with backBehavior: 'initialRoute' and swipeEnabled: false.

On iOS the edge-swipe is the parent stack's native gesture; when it completes it dispatches GO_BACK, which react-navigation offers to the focused descendant (the tab navigator) first. Because you're on the Odometer tab and backBehavior is initialRoute, the TabRouter consumes that GO_BACK by switching back to the first tab (Map) instead of letting it bubble up to pop the RHP. The screen the gesture animated away therefore snaps back into view on the Map tab — the brief flash — before a subsequent back finally dismisses it.

PR #93268 (where this was caught) fixed the equivalent Android case by intercepting the TabRouter back with a BackHandler on hardwareBackPress — but that listener never fires for the iOS native edge-swipe, so iOS was left uncovered. In this repro no data is entered, so the discard-changes machinery is inert; the flash is purely the tab navigator eating the back gesture.

Evidence

• backBehavior: 'initialRoute' (shared by every OnyxTabNavigator): src/libs/Navigation/OnyxTabNavigatorConfig/index.ts:8
• Tabs un-swipeable, so the only back input on iOS is the parent stack edge-swipe → GO_BACK: src/libs/Navigation/OnyxTabNavigator.tsx:196
• Android-only interception (hardwareBackPress) — does not cover the iOS swipe: src/hooks/useDiscardChangesConfirmation/index.native.ts:78-92

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

Make a GO_BACK on a non-first tab dismiss the whole RHP on iOS instead of falling through to the TabRouter's initialRoute tab switch. Preferred option (a):

• (a) In the focused step screen / tab host, intercept GO_BACK while not on the first tab and, when there are no unsaved changes, dispatch a real RHP dismiss (close the flow) rather than letting the TabRouter swallow it as a tab switch — mirroring on the iOS gesture path what PR fix: Discard changes modal does't show up when going back with the browser back button #93268's BackHandler already does for Android hardwareBackPress. This keeps the change scoped to the distance/IOU tab flows.

Alternatives considered:

• (b) Change backBehavior to 'history' (or a custom router) so a non-first tab doesn't consume GO_BACK. ⚠️ backBehavior is shared by every OnyxTabNavigator, so this has broad cross-flow impact and would change tab back behavior app-wide — riskier.
• (c) Intercept at the OnyxTabNavigator level generically. More reusable than (a) but still touches shared navigation; needs careful regression testing of all tab flows.

What alternative solutions did you explore?

See (b) and (c) above. The narrow per-flow fix (a) is the lowest-risk and most directly mirrors the existing Android fix.

---

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

[MobileMage]

Proposal

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

On iOS native, opening the FAB > Track distance, selecting the Odometer entry method, then swiping back to leave the flow makes the "Track distance" screen flash back into view before it animates away. The back-swipe should dismiss the flow in one clean transition, with no screen re-appearing mid-animation.

What is the root cause of that problem?

The Track distance flow is a single RHP screen (DistanceRequestStartPage) whose Map / Manual / GPS / Odometer methods are tabs inside one OnyxTabNavigator. The Odometer tab renders IOURequestStepDistanceOdometer, which calls useDiscardChangesConfirmation to guard against losing typed odometer readings. On native that hook registers the React Navigation removal guard unconditionally:

usePreventRemove(true, ({data}) => { ... });

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

Lines 66 to 76 in 2746256

	usePreventRemove(true, ({data}: {data: {action: NavigationAction}}) => {
	// The action delivered here carries react-navigation's visited-routes marker, so re-dispatching it skips this screen's prevention
	if (isReplayingBlockedNavigation.current || !hasUnsavedChanges()) {
	navigationRef.current?.dispatch(data.action);
	return;
	}
	if (isDiscardModalOpen.current) {
	return;
	}
	showDiscardModal(data.action);
	});

Passing true as the first argument marks the route as preventRemove for its entire lifetime, regardless of whether anything is unsaved. The native stack wires that flag straight to the iOS screen: isRemovePrevented = preventedRoutes[route.key]?.preventRemove becomes preventNativeDismiss={isRemovePrevented} (@react-navigation/native-stack v7.14.5, views/NativeStackView.native.tsx). The platform then never lets the native back-swipe dismiss the screen on its own.

With preventNativeDismiss on, completing the edge-swipe does not dismiss the screen. iOS cancels the gesture (firing onNativeDismissCancelled, which snaps the screen back into place), and only then does React Navigation run the beforeRemove listener. The user opened the Odometer tab and typed nothing, so hasUnsavedChanges() is false and the listener re-dispatches the pop in JS (navigationRef.current?.dispatch(data.action)). That produces two transitions instead of one: the native swipe animates the screen partway out, the cancel snaps it back to full-screen, then the JS pop animates it out again. The Track distance screen re-appears and blinks before it leaves.

The screen that springs back is the same Odometer screen, still on the Odometer tab. This is the native-dismiss cancel/replay, not a tab switch: on iOS the swipe is the parent native-stack pop gesture, and preventNativeDismiss intercepts it before any GO_BACK reaches the tab router. So OnyxTabNavigator's backBehavior plays no part, and a single swipe dismisses the whole RHP rather than getting stuck on a first tab.

History. The issue links PR #93268, whose QA surfaced this. #93268 rewrote the guard to the literal usePreventRemove(true, …) and added useDiscardChangesConfirmation to the other distance entry screens (IOURequestStepDistance, IOURequestStepDistanceMap, IOURequestStepDistanceManual) and the DistanceRequestStartPage host, which previously had no guard, so the same blink now affects every Track distance tab. On the Odometer tab in this repro the blink also occurred before #93268, because the prior guard usePreventRemove(!shouldAllowNavigation, …) (with shouldAllowNavigation defaulting to false) already evaluated to true at the start of a back-swipe. The underlying defect is the unconditional native-dismiss block.

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

Make preventRemove reactive to whether there is something to discard, instead of hard-coding true. The hook already computes the exact signal in hasUnsavedChanges() (focused, not saving, and the screen-supplied getHasUnsavedChanges()), so pass it as the first argument:

usePreventRemove(hasUnsavedChanges(), ({data}) => {
    if (isReplayingBlockedNavigation.current || !hasUnsavedChanges()) {
        navigationRef.current?.dispatch(data.action);
        return;
    }
    ...
});

When nothing is unsaved, preventRemove is false, preventNativeDismiss is false, the native swipe dismisses the screen in one clean animation, and beforeRemove never preventDefaults, so there is no JS re-dispatch and no blink. When there is unsaved input, hasUnsavedChanges() is true, prevention engages, and the discard modal shows as today. The in-callback !hasUnsavedChanges() guard stays as a safety net.

This change is shared by all 10 consumers of the hook, so preventRemove has to re-evaluate whenever each screen's dirty state changes. The consuming screen has to re-render when its input changes. I went through them:

• 7 already re-render on input, so a render-time hasUnsavedChanges() stays current: IOURequestStepDescription and IOURequestStepMerchant (controlled useState text), IOURequestStepDistance and IOURequestStepDistanceMap (waypoints live in the Onyx transaction), IOURequestStepDistanceOdometer (its startReading / endReading are useState, set alongside the refs on every keystroke), and the two avatar pages (isDirty derived from state).
• 3 do not. IOURequestStepAmount, IOURequestStepHours and IOURequestStepDistanceManual keep the typed value in a child number-input ref (amountFormRef / moneyRequestTimeInputRef / numberFormRef), and their onAmountChange / onInputChange only clears formError, so the parent does not re-render on a keystroke. A purely render-time evaluation would keep preventRemove = false even after the user types: the native swipe would dismiss them without firing the guard, and the discard modal would never show. That is the trap in the otherwise-correct one-line version of this fix.

To cover those three, have the hook expose a re-check and call it from their existing change handler, so it re-evaluates hasUnsavedChanges() (which reads the fresh ref) the moment input becomes dirty:

// useDiscardChangesConfirmation/index.native.ts
const [, recheckUnsavedChanges] = useReducer((count: number) => count + 1, 0);
// ...
return { notifySaving, recheckUnsavedChanges };

// IOURequestStepHours / IOURequestStepDistanceManual: existing onInputChange
onInputChange={() => {
    recheckUnsavedChanges();
    if (formError) {
        setFormError('');
    }
}}

For IOURequestStepAmount, forward MoneyRequestAmountForm's amount change up via a small onAmountChange prop that calls recheckUnsavedChanges (the form swallows the change internally today). The 7 reactive screens need no change.

Net result: a clean screen on any tab and any consumer dismisses with a single native animation and no blink; a dirty screen still blocks the dismiss and shows the discard modal. Android stays unaffected, since the separate BackHandler listener handles its back and reads hasUnsavedChanges() directly rather than preventRemove.

What alternative solutions did you explore? (Optional)

• Keep usePreventRemove(true) and stop the blink in JS (re-dispatch before the native restore). This fights react-navigation's gesture lifecycle and breaks across iOS versions; the cancel-then-snap-back is native, and JS cannot suppress it once preventNativeDismiss is on.
• The one-line usePreventRemove(hasUnsavedChanges()) change on its own. Removes the Odometer/Map blink but regresses the discard prompt on the three ref-based screens above, so the per-consumer re-check is needed for a complete fix.
• Changing OnyxTabNavigator's backBehavior. Not the iOS driver (the screen springs back on the same Odometer tab via preventNativeDismiss, not a tab switch), and backBehavior is shared by every tab navigator app-wide, so it would be off-target and broadly risky.
• Disabling the gesture or special-casing only the Odometer screen. Rejected; gestures should stay on, and the defect is generic to the shared hook, so a one-off would leave the same blink on every other consumer.

[lorretheboy]

Proposal

What is the root cause of that problem?

The native discard-changes hook registers usePreventRemove with a hard-coded true, so it intercepts every back/swipe-dismiss of the screen regardless of whether anything is actually unsaved:

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

Lines 66 to 76 in 2746256

	usePreventRemove(true, ({data}: {data: {action: NavigationAction}}) => {
	// The action delivered here carries react-navigation's visited-routes marker, so re-dispatching it skips this screen's prevention
	if (isReplayingBlockedNavigation.current || !hasUnsavedChanges()) {
	navigationRef.current?.dispatch(data.action);
	return;
	}
	if (isDiscardModalOpen.current) {
	return;
	}
	showDiscardModal(data.action);
	});

On the "Track distance" / Odometer step there are no unsaved changes when you just open it and tap Odometer, so hasUnsavedChanges() returns false and the callback simply re-dispatches data.action. But because prevention is always engaged, the iOS native back-swipe is blocked after the gesture has already animated the card away → react-navigation restores (re-focuses) the card, snapping it fully back into view → the re-dispatched action then pops it again. That restore-then-pop is the visible blink of the "Track distance" screen.

The chain: usePreventRemove(true, …) blocks the native swipe unconditionally → on a clean screen the gesture is cancelled and the card springs back to focused → callback re-dispatches the back action → card leaves a second time → user sees the screen flash.

The web hook does not have this bug because it returns early without calling preventDefault() when the screen is clean, leaving the navigation untouched:

App/src/hooks/useDiscardChangesConfirmation/index.ts

Lines 83 to 85 in 2746256

	if (!hasUnsavedChanges()) {
	return;
	}

So the native side is over-blocking relative to the intended behavior.

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

Make the native usePreventRemove condition reactive instead of constant — only engage prevention when the screen is actually dirty, mirroring the web behavior. Evaluate the existing hasUnsavedChanges() (which already gates on focus and in-flight saves) at render time and pass it as the first argument:

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

Line 26 in 2746256

const hasUnsavedChanges = () => isFocused && !isSavingRef.current && getHasUnsavedChanges();

i.e. usePreventRemove(hasUnsavedChanges(), …) instead of usePreventRemove(true, …). The in-callback !hasUnsavedChanges() guard stays as a safety net.

With this, a clean "Track distance"/Odometer screen no longer blocks the iOS swipe — the native gesture completes in one smooth animation with no re-dispatch, so the card never springs back and the blink is gone. When the screen genuinely has unsaved input, prevention engages exactly as before and the discard modal still shows.

What alternative solutions did you explore? (Optional)

Keep prevention on but suppress the re-focus on the no-changes path by re-dispatching synchronously before the native restore can run — but this fights react-navigation's gesture lifecycle and is fragile across iOS versions. Gating the prevention flag on real dirtiness is simpler and matches what the web hook already does.

[abbasifaizan70]

Proposal

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

On iOS, opening the FAB → "Track distance" → tapping the Odometer tab and then swiping back to dismiss the screen causes the "Track distance" screen to briefly re-appear (blink) before it finally dismisses. The previous screen (Inbox) should be shown immediately without the "Track distance" screen flashing.

What is the root cause of that problem?

The Odometer step registers a discard-changes guard via useDiscardChangesConfirmation. On creation it passes a getHasUnsavedChanges callback that returns false until the user actually types a reading or attaches an image, so with no input it reports "no unsaved changes":

App/src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx

Lines 519 to 549 in fd2b949

	useDiscardChangesConfirmation({
	onCancel: () => {
	InteractionManager.runAfterInteractions(() => {
	lastFocusedInputRef.current?.focus();
	});
	},
	getHasUnsavedChanges: () => {
	if (
	!isFocused ||
	isEditing ||
	shouldBypassDiscardConfirmationRef.current ||
	didSaveEditingConfirmationRef.current ||
	!hasInitializedRefs.current ||
	backupHandledManually.current
	) {
	return false;
	}
	const hasReadingChanges = startReadingRef.current !== initialStartReadingRef.current || endReadingRef.current !== initialEndReadingRef.current;
	const hasImageChanges =
	getOdometerImageUri(transaction?.comment?.odometerStartImage) !== getOdometerImageUri(initialStartImageRef.current) ||
	getOdometerImageUri(transaction?.comment?.odometerEndImage) !== getOdometerImageUri(initialEndImageRef.current);
	return hasReadingChanges || hasImageChanges;
	},
	onConfirm: isEditingConfirmation
	? async () => {
	await restoreOriginalTransactionFromBackupWithImageCleanup(transactionID, isTransactionDraft);
	backupHandledManually.current = true;
	}
	: undefined,
	onVisibilityChange: setIsDiscardModalVisible,
	});

The iOS implementation of that hook calls usePreventRemove(true, ...) — it unconditionally prevents the screen's removal. Because the first argument is always true, react-native-screens intercepts every native swipe-back gesture: the in-progress dismissal is cancelled and the screen is snapped back fully into view, and only then does the JS callback run. When there are no unsaved changes the callback simply re-dispatches the navigation action (navigationRef.current?.dispatch(data.action)) to complete the dismissal. The snap-back (screen returns to full view) followed by the re-dispatched dismissal is exactly the brief re-appearance of the "Track distance" screen.

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

Lines 66 to 76 in fd2b949

	usePreventRemove(true, ({data}: {data: {action: NavigationAction}}) => {
	// The action delivered here carries react-navigation's visited-routes marker, so re-dispatching it skips this screen's prevention
	if (isReplayingBlockedNavigation.current || !hasUnsavedChanges()) {
	navigationRef.current?.dispatch(data.action);
	return;
	}
	if (isDiscardModalOpen.current) {
	return;
	}
	showDiscardModal(data.action);
	});

So even when nothing needs to be discarded, the gesture is always intercepted, cancelled, and replayed — producing the flash. The removal should only be prevented when there are genuinely unsaved changes; otherwise the native swipe-back should complete naturally without interception.

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

Make the first argument of usePreventRemove reactive so it only prevents removal when there actually are unsaved changes. When there are none, the native iOS gesture completes without being cancelled/replayed, eliminating the blink. The re-dispatch / discard-modal paths still apply whenever changes exist.

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

Lines 66 to 76 in fd2b949

	usePreventRemove(true, ({data}: {data: {action: NavigationAction}}) => {
	// The action delivered here carries react-navigation's visited-routes marker, so re-dispatching it skips this screen's prevention
	if (isReplayingBlockedNavigation.current || !hasUnsavedChanges()) {
	navigationRef.current?.dispatch(data.action);
	return;
	}
	if (isDiscardModalOpen.current) {
	return;
	}
	showDiscardModal(data.action);
	});

const shouldPreventRemoval = hasUnsavedChanges();

usePreventRemove(
  shouldPreventRemoval,
  ({ data }: { data: { action: NavigationAction } }) => {
    // The action delivered here carries react-navigation's visited-routes marker, so re-dispatching it skips this screen's prevention
    if (isReplayingBlockedNavigation.current || !hasUnsavedChanges()) {
      navigationRef.current?.dispatch(data.action);
      return;
    }
    if (isDiscardModalOpen.current) {
      return;
    }
    showDiscardModal(data.action);
  },
);

With shouldPreventRemoval computed at render time, an unchanged Odometer screen reports false, so usePreventRemove no longer arms the native gesture interception and the swipe-back dismisses straight to the previous screen with no re-appearance. Since getHasUnsavedChanges is driven by the startReading/endReading state (and the transaction's image fields from Onyx), the value re-evaluates on every relevant render, so the guard still engages the moment the user enters a reading or attaches an image.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-29 21:09:01 UTC.

Proposal

What is the root cause of that problem?

The Track distance screen is opened in the RHP, which on iOS is a native stack (@react-navigation/native-stack → react-native-screens).

Every distance tab (Map / Manual / GPS / Odometer) mounts useDiscardChangesConfirmation, and on native that hook registers the removal guard with an unconditional true:

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

Line 79 in 8fa661f

usePreventRemove(true, ({data}: {data: {action: NavigationAction}}) => {

React Navigation forwards an active usePreventRemove to the native screen as preventNativeDismiss: true. On iOS that flag makes the interactive swipe-back gesture non-completing: the card follows the finger off-screen, the OS then cancels the dismissal and animates the card back in (this is the "Track distance screen briefly appears"), fires onNativeDismissCancelled, and the pop is re-dispatched from JS — which finally removes the screen.

Because the guard is registered unconditionally, this happens even when nothing has been entered, so a freshly-opened Track distance screen bounces on every tab. It is unrelated to the tab navigator / backBehavior / routing: on-device instrumentation shows no tab-router state change, no route change, and no JS re-render during the flash — it is purely the native dismissal being prevented and then re-applied.

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

Pass a reactive value to usePreventRemove instead of a constant true, so the screen only blocks the native dismissal when there are genuinely unsaved changes to confirm:

- usePreventRemove(true, ({data}: {data: {action: NavigationAction}}) => {
+ usePreventRemove(hasUnsavedChanges(), ({data}: {data: {action: NavigationAction}}) => {

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

Line 79 in 8fa661f

usePreventRemove(true, ({data}: {data: {action: NavigationAction}}) => {

hasUnsavedChanges() (defined just above) already combines isFocused, the saving ref, and the caller's getHasUnsavedChanges():

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

Line 41 in 8fa661f

const hasUnsavedChanges = () => isFocused && !isSavingRef.current && getHasUnsavedChanges();

With this, a pristine screen has preventNativeDismiss: false and the swipe dismisses cleanly (no bounce), while the discard-changes confirmation still fires when the user has actually entered something — the in-callback hasUnsavedChanges() check and the discard modal are unchanged.

What alternative solutions did you explore? (Optional)

• Forcing backBehavior: 'none' on iOS and/or adding a missing Odometer route in startDistanceRequest. On-device instrumentation showed the blink occurs with no tab-router state change and no route change on any tab, so these do not address the cause.
• A beforeRemove / Navigation.closeRHPFlow() guard at the parent stack — the pop is already dispatched correctly; the flash is the native preventNativeDismiss bounce one layer below, so a JS-level guard does not remove it.

[kitvasyl]

Proposal

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

On iOS, swiping back from the Odometer screen briefly reveals the Track distance method-selection screen before returning to the previous screen.

What is the root cause of that problem?

src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx is opened above the Track distance screen in the navigation stack. The iOS interactive pop gesture therefore renders that intermediate route underneath the Odometer screen during the swipe, even though the flow subsequently returns to the Inbox/report.

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

When selecting Odometer from the Track distance screen, replace the method-selection route with the Odometer route instead of pushing Odometer on top of it. Preserve the original backToReport/previous-screen parameters so IOURequestStepDistanceOdometer returns directly to the originating Inbox or report. This removes the intermediate Track distance route from the stack, so it cannot appear during the native iOS back gesture.

What alternative solutions did you explore? (Optional)

We could disable the native swipe gesture or intercept the removal in IOURequestStepDistanceOdometer, but that would degrade native navigation behavior and only mask the incorrect stack structure.

[melvin-bot]

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

[neerajbachani]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-30 10:05:13 UTC.

Proposal

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

On iOS native, FAB → Track distance → Odometer → edge swipe back does not dismiss cleanly. Applause sees the Track distance screen blink before landing on Inbox (#94904, caught during regression QA for #93268).

Extended finding (same flow, same screen, worse when input exists):
If the user types an odometer reading or attaches an image and then edge-swipes back, the chat list flashes underneath the RHP, the Odometer screen snaps back into view, and only then does the discard-changes modal appear — or swipe-back never surfaces the modal reliably. Header back on the same dirty form shows the discard modal correctly, without the chat glimpse.

Both symptoms are iOS native app only. mWeb and Android do not reproduce the same visual glitch on the same steps.

---

What is the root cause of that problem?

Where the guard lives

The Odometer tab registers useDiscardChangesConfirmation from IOURequestStepDistanceOdometer.tsx. On native, that shared hook is what connects discard-changes UX to React Navigation's removal prevention and, on iOS, to react-native-screens preventNativeDismiss.

Navigation stack for context:

RightModalNavigator          ← iOS edge-swipe gesture owner
  └── MoneyRequestModalStackNavigator
        └── DistanceRequestStartPage
              └── OnyxTabNavigator
                    └── IOURequestStepDistanceOdometer  ← useDiscardChangesConfirmation

Relationship to #93268

#93268 (merged) fixed browser back and Android hardware back not showing the discard modal in tabbed distance flows. It:

• Rewrote the native discard hook around usePreventRemove and added a BackHandler for tab-router backs that never fire beforeRemove
• Extended the same hook to Map / Manual distance tabs (not only Odometer)
• Set web OnyxTabNavigator backBehavior: 'none' so browser history does not trap users on tab switches

What #93268 did not cover: the iOS interactive edge-swipe path. Android hardware back goes through BackHandler (returns false when clean). Browser back goes through the web hook's useBeforeRemove, which returns without blocking when clean. iOS swipe is a native-stack POP with preventNativeDismiss — a third path #93268 never addressed.

#94904 was filed from #93268 QA precisely because that gap remains: Odometer + iOS swipe + clean form still blinks.

The native/web mismatch (core defect)

On main, native always arms prevention:

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

const hasUnsavedChanges = () => isFocused && !isSavingRef.current && getHasUnsavedChanges();

usePreventRemove(true, ({data}: {data: {action: NavigationAction}}) => {
    if (isReplayingBlockedNavigation.current || !hasUnsavedChanges()) {
        navigationRef.current?.dispatch(data.action);
        return;
    }
    if (isDiscardModalOpen.current) {
        return;
    }
    showDiscardModal(data.action);
});

The first argument is hard-coded true, so preventRemove / preventNativeDismiss is registered for the route's entire lifetime, even when hasUnsavedChanges() is false.

The web hook does the opposite — it only blocks when dirty:

App/src/hooks/useDiscardChangesConfirmation/index.ts

useBeforeRemove((e) => {
    if (!hasUnsavedChanges()) {
        return; // no preventDefault → navigation proceeds natively / via history
    }
    e.preventDefault();
    // ...
});

Native over-blocks relative to web: the JS callback knows when the form is clean and re-dispatches data.action, but only after iOS has already cancelled the in-flight native dismiss.

How true becomes a blink on iOS (clean Odometer — filed repro)

@react-navigation/native-stack maps usePreventRemove(true) → preventNativeDismiss={true} on the screen. When the user completes an edge swipe:

1. Native stack starts the POP animation (chat becomes visible under the sliding RHP)
2. preventNativeDismiss blocks completion → screen snaps back to full view
3. JS beforeRemove runs → !hasUnsavedChanges() → navigationRef.dispatch(data.action) again
4. User sees two transitions for one gesture = Track distance blink

Applause's steps (Odometer tab, no input) hit exactly this: prevention is armed but pointless.

How the same mechanism breaks dirty Odometer (extended finding)

When the user has typed a reading, hasUnsavedChanges() is correctly true and prevention is legitimate. The same native lifecycle still runs before JS can show the discard modal:

1. Edge swipe starts native POP → chat visible under RHP
2. preventNativeDismiss cancels → snap back to Odometer
3. Then showDiscardModal() runs

Header back avoids the glimpse because it never starts the interactive native POP — it goes straight to closeRHPFlow / beforeRemove without animating chat underneath first.

Device investigation confirmed the flash is not a tab switch: selectedTab stays distance-odometer throughout; the screen that springs back is the same Odometer tab, not Map.

Why this is not TabRouter / backBehavior

Some theories point at OnyxTabNavigator backBehavior: 'initialRoute' (Android hardware-back territory, #94863). iOS edge swipe here is a parent native-stack POP, not a TabRouter GO_BACK consumed before the RHP closes. Traces and tab state rule that out for this issue.

Why Android and mWeb are unaffected

Android — native stack sets gestureEnabled: false; dirty back uses the hook's BackHandler, which reads hasUnsavedChanges() directly:

BackHandler.addEventListener('hardwareBackPress', () => {
    if (!hasUnsavedChanges()) {
        return false; // hand off to React Navigation
    }
    showDiscardModal();
    return true;
});

mWeb — no preventNativeDismiss; web tabs use backBehavior: 'none' (from #93268) so browser back leaves the whole flow.

---

Why one change alone does not complete the fix

Both the filed blink and the extended dirty swipe share one RCA — iOS preventNativeDismiss lifecycle in useDiscardChangesConfirmation — but they manifest at opposite ends of the same flag:

Manifestation	hasUnsavedChanges()	What goes wrong on main	Required fix
#94904 (Applause)	false	usePreventRemove(true) arms prevention anyway → snap-back + JS re-dispatch → blink	Part A: usePreventRemove(shouldPreventRemoval) only when dirty
Extended finding	true	Legitimate prevention still lets native POP start → chat glimpse / unreliable modal	Part B: disable ancestor swipe when dirty + custom edge pan → showDiscardModal()

Part A alone fixes clean swipe but leaves dirty swipe broken (or glimpsing). Part B alone does not stop the clean-form blink. Both parts are required for a complete fix on the same hook.

---

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

Core surface: App/src/hooks/useDiscardChangesConfirmation/index.native.ts

Part A — reactive prevention (filed #94904 / clean Odometer)

Mirror the web hook's intent: only arm prevention when there is something to discard.

  const hasUnsavedChanges = () => isFocused && !isSavingRef.current && getHasUnsavedChanges();
+ const shouldPreventRemoval = hasUnsavedChanges();

- usePreventRemove(true, ({data}) => {
+ usePreventRemove(shouldPreventRemoval, ({data}) => {
      if (isReplayingBlockedNavigation.current || !hasUnsavedChanges()) {
          navigationRef.current?.dispatch(data.action);
          return;
      }
      // ...
  });

Expose recheckUnsavedChanges() for screens that store typed values only in imperative refs (IOURequestStepAmount, IOURequestStepHours, IOURequestStepDistanceManual) so shouldPreventRemoval updates on keystroke.

Part B — dirty iOS swipe path (extended finding)

When shouldPreventRemoval is true on iOS:

1. Disable native edge swipe on every ancestor stack (navigation.getParent() loop through RightModalNavigator), restoring gestureEnabled: true on cleanup or when clean — prevents native POP from starting and exposing chat.
2. Register a narrow left-edge pan guard (below header, not overlapping header back) that calls showDiscardModal() so dirty swipe-back still prompts the user.

Mount the guard once from ScreenWrapper via a small provider in the hook module. iOS-only; Android BackHandler from #93268 unchanged.

Expected behavior (both parts shipped)

Case	Edge swipe	Header back
Clean Odometer	One native dismiss → Inbox, no blink	Closes flow
Dirty Odometer	Edge pan → discard modal, no chat glimpse	Discard modal, no glimpse

---

What alternative solutions did you explore?

• Tab backBehavior / per-flow GO_BACK intercept — wrong router for iOS swipe; traces show no Map tab flash.