[$250] Discard changes modal does't show up when going back with the browser back button

[mitarachim]

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.3.31-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: #78291
Email or phone of affected tester (no customers): applausetester+ds@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 14.5/ Chrome
App Component: Other

Action Performed:

1. Click on the + button > Track Distance
2. Switch to Odometer
3. Write a number on the fields
4. Click on the browser back

Expected Result:

Discard changes modal shows up, user can't go back.

Actual Result:

Discard changes modal doesn't shows up, user go back.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7094082_1772659282253.Screen_Recording_2026-03-05_at_12.01.09_at_night.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029450072204619790
• Upwork Job ID: 2029450072204619790
• Last Price Increase: 2026-03-05

[melvin-bot]

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

[MelvinBot]

Proposal

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

When creating a new distance request via Track Distance > Odometer tab, entering values in the odometer fields and then pressing the browser back button navigates the user away without showing the "Discard changes" confirmation modal. The user's input is silently lost.

What is the root cause of that problem?

IOURequestStepDistanceOdometer already integrates DiscardChangesConfirmation (rendered at line 646, with hasUnsavedChanges computed at lines 500-505). However, the discard-changes mechanism fails specifically for browser back because of a navigation context mismatch.

When creating a new request (isCreatingNewRequest = true), the odometer component is rendered as a tab inside DistanceRequestStartPage's OnyxTabNavigator (a MaterialTopTabNavigator) — see DistanceRequestStartPage.tsx:229-239. In this context, shouldShowWrapper is false (line 513 of the odometer file), meaning the odometer component does not have its own stack screen — it lives inside a tab screen.

The web implementation of DiscardChangesConfirmation (index.tsx:35-51) uses navigation.addListener('transitionStart', ...) to detect browser back navigation and reverse it with window.history.go(1). The navigation object comes from useNavigation() (line 14), which returns the nearest navigator — in this case, the MaterialTopTabNavigator.

The problem: MaterialTopTabNavigator does not emit transitionStart events. This event is only emitted by stack navigators. So when the user presses browser back, the browser navigates away, the parent stack screen (DISTANCE_CREATE) is removed, but the transitionStart listener on the tab navigator never fires. The window.history.go(1) reversal never executes, and the modal never appears.

In contrast, pages like IOURequestStepMerchant and IOURequestStepDescription always use shouldShowWrapper (they are standalone stack screens), so their DiscardChangesConfirmation correctly listens for transitionStart on a stack navigator.

Note: The usePreventRemove mechanism inside DiscardChangesConfirmation (line 22-28) does propagate through nested navigators via PreventRemoveProvider context, so programmatic back navigation (e.g., pressing the header back button) IS correctly blocked. The bug is exclusively about browser back on web.

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

The DiscardChangesConfirmation web implementation (index.tsx) should listen for transitionStart on the parent stack navigator instead of just the nearest navigator when it's rendered inside a tab navigator. This can be done by using navigation.getParent() to obtain the parent stack navigator and attaching the transitionStart listener to it. If getParent() returns a navigator that supports transitionStart (i.e., a stack navigator), use that; otherwise fall back to the current navigation object.

Alternatively, the DistanceRequestStartPage could accept and forward a parent navigation ref, or the DiscardChangesConfirmation component could walk up the navigator hierarchy until it finds one that supports transitionStart.

What alternative solutions did you explore? (Optional)

1. Moving DiscardChangesConfirmation to DistanceRequestStartPage itself — This would place it in the correct stack navigator context, but would require DistanceRequestStartPage to track hasUnsavedChanges across all its child tabs, adding complexity.
2. Listening on window popstate event directly instead of relying on React Navigation's transitionStart — This would work regardless of navigator type but may conflict with React Navigation's own URL state management.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

📣 @SolariSystems! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[ShridharGoel]

@MelvinBot Implement it, while having a prop called useParentStackForWebBack which will be passed as true for odometer only.