Native share - Unable to upload photo when shared from gallery

[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: 9.3.36-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83359
Email or phone of affected tester (no customers): sjodijsnodijdnoijsido@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Chat Report View

Action Performed:

1. Open an image from gallery.
2. Share it to Expensify app.
3. Select any chat.
4. Tap Share.

Expected Result:

Attachment will be uploaded.

Actual Result:

Attachment cannot be uploaded when shared from gallery.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7100361_1773261296832.Screen_Recording_20260312_043339_Expensify.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #83359

[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

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

When sharing a photo from the device gallery to the Expensify app via the native share sheet on Android or iOS, the attachment cannot be uploaded. The user can navigate through the share flow (select chat, tap Share) but the upload fails. This is reproducible in staging but not production, pointing to a recent merge as the cause.

What is the root cause of that problem?

PR #83359 ("Enable platform tree shaking in hermes bundle") re-enabled experimentalImportSupport: true in metro.config.js and disableImportExportTransform: true in babel.config.js. These flags change how ES module import/export statements are compiled in the Metro bundle, switching from Babel's @babel/plugin-transform-modules-commonjs (which supports lazy evaluation) to Metro's own import-export-plugin (which evaluates eagerly).

This is the second time these exact flags have been tried and broken native share. The identical changes were previously shipped in PR #80110, which was reverted via PR #80984 for causing three regressions — including #80838 ("Native share - Unexpected error appears in chat when sharing an image"), which is the same symptom as this issue. PR #83359 re-introduced the flags claiming the difference was "Expo Metro config stays untouched," but the same native share regression has recurred, proving the experimentalImportSupport + disableImportExportTransform flags themselves are the root cause.

The specific mechanism: the share flow depends on ShareActionHandlerModule (src/libs/ShareActionHandlerModule/index.ts), which destructures ShareActionHandler from NativeModules at module scope and re-exports it as default. ShareRootPage.tsx imports this and calls ShareActionHandler.processFiles() to retrieve shared file metadata from the native layer. The transform change alters module initialization order and ESM/CJS interop semantics, which can cause the native module reference to be undefined or incorrectly resolved when accessed. Additionally, Metro's experimentalImportSupport has an open bug (facebook/metro#1460) producing incorrect exports for destructured objects, which may affect dependencies in the share flow.

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

Revert PR #83359 — remove experimentalImportSupport: true from metro.config.js and revert babel.config.js to use the default preset without disableImportExportTransform. This is the same fix that resolved the identical regression the first time (PR #80984).

Specifically:

• In metro.config.js: remove the experimentalImportSupport: true line
• In babel.config.js: change back to presets: [require('@react-native/babel-preset')] and revert the Jest-specific override

What alternative solutions did you explore? (Optional)

1. Targeted fix for ShareActionHandlerModule — changing the export pattern from export default ShareActionHandler to a named export, or accessing NativeModules.ShareActionHandler lazily instead of at module scope. However, since the same flags also cause PDF display and tag import regressions (as seen in the original revert), a targeted fix for just the share flow would leave the other issues unresolved.

2. Adding affected modules to nonInlinedRequires — Metro's inlineRequires can be configured to skip specific modules, which might help with initialization order. However, this doesn't address the fundamental ESM/CJS interop changes or Metro bug Use OSBotify instead of botify #1460, and would be a partial workaround rather than a proper fix.

---

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.