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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #83359 - "Enable platform tree shaking in hermes bundle" by @rinej (High confidence)
Related Issues: This is the exact same regression that was previously caused by PR #80110 and reverted via PR #80984

Recommendation: REVERT

PR #83359 must be reverted immediately. This PR re-enabled experimentalImportSupport: true in metro.config.js and disableImportExportTransform: true in babel.config.js, which breaks native module initialization for the share flow.

Critical context: These exact config changes were previously attempted in PR #80110 (merged Jan 28, 2026) and caused three deploy blockers:

• Native share - Unexpected error appears in chat when sharing an image #80838 - Native share error (identical to this issue)
• Scan-PDF receipt is not displayed when opened for the first time #80864 - PDF receipt display failure
• Tags - Import multi-level tags to workspace is failed #80844 - Tag import failure

PR #80110 was reverted on Jan 30, 2026 via PR #80984. PR #83359 re-introduced the same changes on Mar 10, 2026, claiming "Expo Metro config stays untouched" as the difference. However, the native share regression has recurred, proving the root cause is the experimentalImportSupport + disableImportExportTransform flags themselves, not the Expo config.

Labels: This is a frontend bug requiring an App PR revert. Both DeployBlockerCash and DeployBlocker labels are currently applied. Since this blocks the App deploy and the fix requires reverting an App PR, I am keeping DeployBlockerCash and removing DeployBlocker.

Detailed Analysis

Evidence

1. Issue symptoms match exactly: "Attachment cannot be uploaded when shared from gallery" - identical to issue Native share - Unexpected error appears in chat when sharing an image #80838 from the previous attempt
2. Staging-only reproduction: Bug appears in staging (9.3.36-0) but not production, confirming it was introduced by a recent PR
3. PR Enable platform tree shaking in hermes bundle #83359 is in the deploy: Listed in StagingDeployCash #84953 at position 2 in chronological order (merged Mar 10, 2026 at 19:44:56 UTC)
4. MelvinBot analysis: Correctly identified the same root cause and mechanism

Verification

The affected code path:

• ShareRootPage.tsx (line 84): Calls ShareActionHandler.processFiles()
• ShareActionHandlerModule/index.ts (line 3): Destructures ShareActionHandler from NativeModules at module scope
• The Metro/Babel transform changes alter module initialization order and ESM/CJS interop, causing the native module reference to be undefined or incorrectly resolved

Current config state confirms the problematic flags are active:

• metro.config.js line 38: experimentalImportSupport: true
• babel.config.js line 66: disableImportExportTransform: true

Root Cause

The experimentalImportSupport flag switches Metro from Babel's CommonJS transform (which supports lazy evaluation) to Metro's own import-export plugin (which evaluates eagerly). This changes:

1. Module initialization order
2. ESM/CJS interop semantics
3. How destructured NativeModules exports are resolved

The share flow depends on ShareActionHandler being correctly initialized from the native layer. The transform change breaks this initialization, causing the native module to be undefined when accessed.

Additionally, Metro's experimentalImportSupport has a known bug (facebook/metro#1460) that can produce incorrect exports for destructured objects, which may affect the share flow dependencies.

Why This Keeps Happening

The bundle size reduction (8%, ~2.9 MB) from tree shaking is attractive, but the implementation approach is fundamentally incompatible with how the app's native modules are currently structured. Without refactoring the native module access patterns (e.g., lazy evaluation, named exports instead of destructuring), these flags will continue to break native integrations.