[$250] Reports - Going back from a replace receipt flow on a scanned expense returns to camera

[nlemma]

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.3.19-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: https://test-management.browserstack.com/projects/2219752/folder/13176933/test-cases/41237717
Email or phone of affected tester (no customers): gatantm+626a@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 12 mini, iOS 16.7, Google Pixel 9 Pro, Android 16
App Component: Chat Report View

Action Performed:

1. Precondition: Scan an expense and wait for it to fail or complete
2. Tap on Reports and select the expense that was scanned (or the report it's in and then the expense)
3. Tap on the receipt and the overflow button
4. Select replace
5. Take a photo
6. Tap back or swipe to go the previous screen

Expected Result:

User is back to main Reports screen.

Actual Result:

User is back to the camera screen to replace the receipt.
The navigation history is bugged. Works fine with a non scanned expense

Steps from @truph01 below too

1. Create two expenses, one of which has a receipt.
2. Tap Reports and select the expense that has the receipt.
3. Select Replace.
4. Take a photo.
5. Tap Back or swipe to return to the previous screen.
6. Observe: The user is taken back to the camera screen to replace the receipt.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7077486_1771029600284.RPReplay_Final1771029087.MP4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @truph01

Upwork Automation - Do Not Edit

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

[mallenexpensify]

@truph01 this seems pretty niche. If we were to fix it, are there other similar instances we could fix at same time? Feel free to tag melvin to ask or for help.

[truph01]

If we were to fix it, are there other similar instances we could fix at same time?

@mallenexpensify Yes, the reproduction steps can be simplified as follows:

1. Create two expenses, one of which has a receipt.
2. Tap Reports and select the expense that has the receipt.
3. Select Replace.
4. Take a photo.
5. Tap Back or swipe to return to the previous screen.

Observe: The user is taken back to the camera screen to replace the receipt.

[truph01]

As you can see, the reproduction steps for this issue are very simple and can occur quite easily. It’s not as niche as the original reproduction steps described in the OP.

[melvin-bot]

Triggered auto assignment to @NicMendonca (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 replacing a receipt on an expense (via Reports → tap receipt → overflow menu → Replace → take photo), pressing back/swiping after capturing the photo returns the user to the camera screen instead of navigating back to the previous screen. This occurs on iOS and Android native apps.

What is the root cause of that problem?

The root cause is that the native navigateBack() function in IOURequestStepScan/index.native.tsx does not pass the backTo parameter to Navigation.goBack(), unlike the web version which correctly does.

Native (index.native.tsx:80-82):

navigateBack → Navigation.goBack()  // No backTo — just pops one screen

Web (index.tsx:89-91):

navigateBack → Navigation.goBack(backTo)  // Uses backTo — navigates to the correct route

Here's the flow that triggers the bug:

1. User opens the receipt modal (TransactionReceiptModalContent)
2. User presses "Replace" — on native this calls Navigation.goBack() to dismiss the receipt modal, then via microtask queue navigates to MONEY_REQUEST_STEP_SCAN with backTo set to Navigation.getActiveRoute() (the receipt modal route)
3. The scan screen opens in the RHP (MoneyRequestModalStackNavigator)
4. User captures a photo → updateScanAndNavigate fires → calls navigateBack() → Navigation.goBack() without backTo

Because goBack() is called without backTo, it simply pops the current screen from the navigation stack rather than using goUp(backTo) to navigate to the correct destination. This leaves the user in an incorrect navigation state where pressing back leads them back to the camera screen.

On web, navigateBack() passes backTo to goBack(), which calls goUp(backTo) — this correctly resolves the target route and navigates there, avoiding the issue entirely.

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

Update navigateBack() in src/pages/iou/request/step/IOURequestStepScan/index.native.tsx to pass backTo to Navigation.goBack(), matching the web behavior:

// Before (line 80-82):
const navigateBack = () => {
    Navigation.goBack();
};

// After:
const navigateBack = () => {
    Navigation.goBack(backTo);
};

This ensures that after taking a replacement photo on native, the navigation correctly goes back to the route stored in backTo (the receipt modal route or the screen the user came from) rather than blindly popping one screen.

The updateScanAndNavigate function (lines 254-272) already has a special case using backTo for when navigation state is lost, but the normal flow path should also use it.

What alternative solutions did you explore? (Optional)

An alternative would be to modify updateScanAndNavigate directly to always use Navigation.goBack(backTo) in its normal flow path (the else branch at line 267), rather than calling navigateBack(). However, since navigateBack is also used for the header back button press (onBackButtonPress={navigateBack} at line 448), fixing navigateBack itself ensures consistent behavior for both the photo capture flow and manual back button presses.

Relevant Code References

• src/pages/iou/request/step/IOURequestStepScan/index.native.tsx:80-82 — Native navigateBack missing backTo
• src/pages/iou/request/step/IOURequestStepScan/index.tsx:89-91 — Web navigateBack correctly using backTo
• src/pages/iou/request/step/IOURequestStepScan/index.native.tsx:254-272 — Native updateScanAndNavigate
• src/pages/media/AttachmentModalScreen/routes/TransactionReceiptModalContent.tsx:510-533 — Replace button navigation (sets backTo)

---

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