iOS - Native share - Unable to submit expense from device media library

[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.60-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-19604/folder/13176721/41236966/1336303697?sort=%2Bidentifier
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 13 iOS 26.3.1
App Component: Money Requests

Action Performed:

1. Open the app
2. On the device media library - Choose a picture or receipt to share
3. Select share to Expensify
4. Choose option to "Submit"
5. Select a workspace
6. Tap "Create expense" button

Expected Result:

Receipt can be successfully shared from the device media library

Actual Result:

Unable to submit expense from device media library, the Create expense button doesn't respond

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7131257_1776333226058.ScreenRecording_04-16-2026_04-51-52_1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @TaduJR

[melvin-bot]

Triggered auto assignment to @yuwenmemon (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

The LocationPermissionModal's onGrant handler in SubmitDetailsPage.tsx:345 re-enters onConfirm with gpsRequired=true, creating a deadlock when location permission is already granted.

The flow is:

1. User taps "Create expense" → onConfirm(participants, true) (gpsRequired hardcoded to true)
2. shouldStartLocationPermissionFlow evaluates true → calls setStartLocationPermissionFlow(true) → returns early
3. LocationPermissionModal effect fires, checks permission — if already granted, calls onGrant() immediately
4. onGrant calls onConfirm(undefined, true) → shouldStartLocationPermissionFlow is true again → setStartLocationPermissionFlow(true) — but it's already true, so no state change, the effect doesn't re-fire, and the button is permanently stuck

The onDeny path works because it passes gpsRequired=false, bypassing the permission check on re-entry.

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

Mirror the pattern used in SubmitExpenseOrchestrator.tsx:161-167: the onGrant callback should directly proceed to create the expense (call readFileAsync + finishRequestAndNavigate) instead of re-entering onConfirm. The onDeny handler already follows a similar direct pattern — onGrant should do the same.

Additionally, the empty error handler () => {} at SubmitDetailsPage.tsx:322 in readFileAsync should show an error to the user instead of silently failing.

Investigation details

Data flow for iOS native share:

1. iOS share sheet → ShareViewController.swift saves file to app group container
2. Deep link new-expensify://share/root opens the app
3. ShareRootPage processes files via native ShareActionHandler, stores in SHARE_TEMP_FILE
4. User selects "Submit" tab → picks workspace → navigates to SubmitDetailsPage
5. Tapping "Create expense" calls MoneyRequestConfirmationList.confirm() → onConfirm(participants, true)
6. Bug: gpsRequired=true always triggers the location permission flow, and the onGrant re-entry creates the deadlock described above

Why this only affects the share flow: The normal expense flow in SubmitExpenseOrchestrator correctly handles onGrant by calling createTransaction directly (line 165), never re-entering the permission check. SubmitDetailsPage was written with a different pattern that re-enters onConfirm.

Secondary issue: readFileAsync at line 318-324 uses () => {} as its error handler. If the shared file's file:// URL becomes inaccessible (e.g., iOS sandbox restrictions, app group container cleanup), the failure is silently swallowed.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[OSBotify]

Investigation Summary: Frontend bug. Causing PR: #87142 by @TaduJR (High confidence). Recommendation: REVERT.

PR 87142 introduced a regression in SubmitDetailsPage.tsx that makes the Create expense button silently unresponsive in the iOS native share flow.

Root cause: The PR changed the onGrant callback for LocationPermissionModal from onGrant={onConfirm} to onGrant={() => onConfirm(undefined, true)}. When location permission was already granted, this creates a loop: onConfirm passes gpsRequired=true, which triggers setStartLocationPermissionFlow(true), LocationPermissionModal immediately calls onGrant() again since location is already granted, onGrant calls onConfirm(undefined, true) again, but since lastLocationPermissionPrompt is only updated on deny (never on grant), shouldStartLocationPermissionFlow is still true, and setStartLocationPermissionFlow(true) is a no-op since state is already true. readFileAsync is never reached and the expense is never created.

The bug is staging-only because PR 87142 was merged April 15, 2026 and is not yet in production.

Files affected: src/pages/Share/SubmitDetailsPage.tsx

Assigned: @TaduJR (PR author), @hoangzinh (approving reviewer), @marcochavezf (approving reviewer)