[$250] mWeb-Web page reloads after sending 3 attachments, the attachments are not sent

[lanitochka17]

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.89-3
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/13176710/test-cases/41236932
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 15 iOS 26.5 Safari
App Component: Chat Report View

Action Performed:

Preconditions: there are some attachments downloaded to Files on the iPhone

1. Open a new incognito window
2. Navigate to staging.new.expensify.com and sign in with a new account
3. Select "Organize my personal spendings" purpose
4. Navigate to the Inbox, tap grey "+" button - Start chat
5. Enter another existing user's email, send a message in the chat
6. Exit and re-enter the chat, tap "+" button - Add attachment - Choose files
7. Select 3 attachments and tap "Open" blue button

Expected Result:

Attachments previews are displayed with a Send button

Actual Result:

The webpage is reloaded, the attachments "Send" modal disappears

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7166482_1780070057896.3_attachments_mweb.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022060427419314785278
• Upwork Job ID: 2060427419314785278
• Last Price Increase: 2026-05-29

[MelvinBot]

Proposal

What is the root cause of that problem?

Confidence: Medium — code paths are confirmed; exact memory threshold on iOS 26.5 Safari was not measured in production.

When the user selects 3 files in the native iOS file picker, iOS Safari reloads/discards the tab while the WebContent process is processing the selection. After the reload, the in‑memory attachment state is gone, so the /r/:reportID/attachment route loads with no file, and a fallback hook navigates back to the report — making the Send modal appear to "disappear."

Two design decisions in the attachment selection chain make the flow fragile under iOS Safari memory pressure:

1. The selected files are kept only in a React useRef on the AttachmentModalContext (src/pages/media/AttachmentModalScreen/AttachmentModalContext.tsx:33-39). They are not part of the navigation params or any persistent store, so any tab reload between "Open" and the modal mount silently drops them.

2. useNavigateToReportOnRefresh treats a missing file as "user refreshed mid‑flow" and immediately navigates back to the chat (src/pages/media/AttachmentModalScreen/routes/hooks/useNavigateToReportOnRefresh.ts:14-27). This is what produces the visible "Send modal disappears" symptom after the Safari reload.

The reload itself is most likely caused by memory pressure during the file selection chain. For 3 files the app:

• Creates 3 blob URLs immediately on onChange (AttachmentPicker/index.tsx:63-74).
• Runs validation in parallel via Promise.all (useFilesValidation.tsx:173-203).
• Inside validateAttachmentFile, calls URL.createObjectURL a second time per file without revoking the first one (src/libs/validateAttachmentFile.ts:71-72) — for 3 files that leaks 3 blob references.
• Loads each image via ImageSize.getSize for corruption validation (FileUtils.ts:369-385) and may also resize via canvas.

iOS 26.5 Safari is known to aggressively discard tabs that spike memory while a native picker is foregrounded; this is consistent with the reload symptom and matches the report ("3 attachments" — fewer files do not reproduce per the BrowserStack test).

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

Two changes are needed. (1) addresses the immediate symptom; (2) reduces the likelihood of the underlying Safari reload.

1. Make the in‑progress attachment selection survive a Safari tab reload. Persist a minimal restore hint (e.g., a flag plus reportID in sessionStorage) when navigating to REPORT_ADD_ATTACHMENT, and on remount, instead of silently navigating back via useNavigateToReportOnRefresh, surface a brief toast like "Your attachments were cleared because the page reloaded — please try again" before returning to the chat. (Blob references themselves cannot survive the reload, so reusing the picked files is not possible — feedback is the realistic fix.)

2. Reduce memory pressure during multi‑file selection on web/mWeb:

   • In validateAttachmentFile.ts:71, reuse the existing file.uri from AttachmentPicker instead of calling URL.createObjectURL a second time, or URL.revokeObjectURL(file.uri) before reassigning. This is a straight leak today.
   • On web/mWeb, validate files sequentially (or in chunks of 1–2) in useFilesValidation.tsx instead of Promise.all for the full set, so canvas/image decode peaks don't stack.

What alternative solutions did you explore? (Optional)

• Persisting the actual files via IndexedDB before navigating — rejected because copying 3 large files into IDB just to immediately read them back would increase the memory pressure that is causing the reload in the first place.
• Removing useNavigateToReportOnRefresh entirely — rejected because the "refreshed in the middle of attachment flow" case still needs to be handled; the fix is to distinguish reload‑with‑intent from a true cold load.

Investigation notes

Flow trace:

1. AttachmentPicker/index.tsx:57-80 — onChange creates blob URLs and calls onPicked.
2. useAttachmentPicker.ts:55-95 — pickAttachments → validateFiles.
3. useFilesValidation.tsx:148-325 — parallel validateAttachmentFile calls.
4. useAttachmentPicker.ts:35-51 — onFilesValidated stores files in AttachmentModalContext ref and navigates to REPORT_ADD_ATTACHMENT.
5. On the new route, AttachmentModalScreen/index.tsx:22-31 merges params with whatever is in the context ref.
6. If the tab was reloaded, the ref is empty → ReportAddAttachmentModalContent has file === undefined → useNavigateToReportOnRefresh fires and goes back to the chat. This matches the user-visible symptom exactly.

Why this only reproduces with 3 files and only on iOS Safari is consistent with iOS Safari's WebContent process being reclaimed under combined blob/canvas memory pressure while the picker is foregrounded; smaller counts stay under the threshold.

Possibly related: #88561 (Receipt selected from gallery can upload as empty on iOS mobile web) — different end-state but same iOS mWeb picker surface; worth checking if the same persistence fix helps it.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92108) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-29 18:35:46 UTC.

Proposal

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

On iOS Safari mWeb, opening a chat and using "+" → Add attachment → Choose files, then selecting 3 attachments and tapping Open, causes the whole page to reload and the attachment "Send" modal to never appear. The reload happens during attachment processing/navigation — before the Send button is ever shown — and is specific to iOS Safari's WKWebView; the same flow works on iOS Chrome, desktop browsers, and native.

What is the root cause of that problem?

This is a renderer-process memory kill, not a thrown JS error. iOS Safari silently reloads a tab when its WKWebView exceeds the per-tab memory ceiling, and the multi-file chat-attachment path decodes every selected image at full resolution multiple times while never releasing the blob URLs it creates. With 3 large photos from the Files app this easily crosses the limit.

Trace the write path. The web picker's onChange mints one object URL per file (URL.createObjectURL) and hands them to pickAttachments → validateFiles → validateAndResizeFiles, which calls validateAttachmentFile for each file. For images that runs validateImageForCorruption, which calls ImageSize.getSize(file.uri) — on web this resolves to react-native-web's Image.getSize, decoding the full-resolution bitmap (a 12MP photo is ~48MB decoded) just to read dimensions. validateAttachmentFile then assigns yet another fresh URL.createObjectURL to file.uri and never revokes it:

App/src/libs/validateAttachmentFile.ts

Lines 70 to 74 in d332c6b

	}
	const inputSource = URL.createObjectURL(updatedFile);
	updatedFile.uri = inputSource;
	return {isValid: true, file: updatedFile};

Now the amplifier on the read path. After onFilesValidated navigates to REPORT_ADD_ATTACHMENT, ReportAddAttachmentModalContent runs the exact same validateAttachmentFile over the already-validated files in a mount effect, decoding every image a second time and minting a second set of blob URLs, before the carousel mounts and decodes them yet again for display:

App/src/pages/media/AttachmentModalScreen/routes/report/ReportAddAttachmentModalContent/index.tsx

Lines 89 to 92 in d332c6b

	const files = Array.isArray(fileParam) ? fileParam : [fileParam];
	const results = await Promise.all(files.map(async (file) => validateAttachmentFile(file)));
	const validResults = results.filter((r) => r.isValid);

So each selected image is decoded at least twice (validation, re-validation) plus once more by the carousel, and every createObjectURL in this path leaks. The codebase already knows the correct pattern — getImageResolution decodes via new Image() and calls URL.revokeObjectURL as soon as it has the dimensions — but the chat attachment path never adopts it. Three full-res decodes ×3 files with zero releases is what tips WKWebView over its limit and forces the reload.

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

Cut the redundant work and stop leaking. First, remove the second validation pass in ReportAddAttachmentModalContent: the only code path that navigates to REPORT_ADD_ATTACHMENT is useAttachmentPicker.onFilesValidated, which has already run every file through validateAttachmentFile in useFilesValidation before navigating, so re-validating in the modal is pure duplicate decoding. We can initialize state directly from the passed-in (already valid) files instead of re-decoding them:

const files = Array.isArray(fileParam) ? fileParam : fileParam ? [fileParam] : [];
const [validFiles, setValidFiles] = useState(files);
const [source, setSource] = useState(() => getValidatedImageSource(sourceParam ?? files.at(0)?.uri));
// drop the validateFiles() useEffect that re-runs validateAttachmentFile on fileParam

Second, follow the existing getImageResolution precedent and revoke object URLs once they are no longer needed in the validation path — release the URL used by validateImageForCorruption/ImageSize.getSize after the dimension read, and revoke the per-file URLs from the picker once the files have been consumed by the modal. This keeps only one decoded copy alive at a time. The change is safe because validateAttachmentFile is only invoked from useFilesValidation and this modal, and removing the modal pass doesn't weaken validation for any other entry point — every file still passes through validation exactly once on its way in.

What alternative solutions did you explore? (Optional)

Reading each file via FileReader.readAsDataURL instead of createObjectURL (as some proposals suggest) is the wrong direction: base64 data URLs hold the entire file in the JS heap and getImageResolution explicitly documents avoiding FileReader for performance, so that would increase memory pressure, not reduce it. Down-scaling images before preview is also heavier than necessary here since the real waste is decoding the same files two-to-three times rather than the single decode the preview legitimately needs.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-29 18:44:37 UTC.

Proposal

What is the root cause of that problem?

The web update checker treats every hidden-page transition as a safe time to update the app. In production, webUpdater.init() calls webUpdate() whenever visibilitychange fires while the page is hidden, and webUpdate() immediately calls window.location.reload() if /version.json does not match the loaded bundle version.

On iOS Safari, opening the native Files picker from our hidden web file input can also make the page hidden while the user is selecting files. The attachment picker does not mark that transient native picker state, so the update checker cannot distinguish it from a real backgrounded tab. If a newer web version is available, the app reloads while the picker is open or just as it closes.

That reload destroys the pending attachment state because the selected File objects and send callbacks are stored only in AttachmentModalContext.currentAttachment, which is an in-memory ref. After the reload, the add-attachment route has no source or file, so useNavigateToReportOnRefresh navigates back to the report. The user lands back in chat with no attachment preview and no Send button.

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

Track the native web file-picker lifecycle and exempt that specific transient hidden state from silent web update reloads.

Concretely:

• In the web AttachmentPicker, mark a file picker as active immediately before calling fileInput.click().
• Clear that active state when the picker returns through change, cancel, or the existing visibility-return close path. While touching this, wire the existing onOpenPicker prop and onClosed picker option on web, since this chat attachment flow already passes those hooks.
• In src/setup/platformSetup/index.ts, check whether a web file picker is active before running webUpdate() from the hidden visibilitychange handler. If it is active, skip or defer that update check until the picker closes or the page becomes visible again.
• If an update check is still needed after the picker closes, run it after visibility returns, so the existing visible-page confirmation path is used instead of silently reloading during attachment selection.

This should be scoped to the web/mWeb attachment picker and the web update gate. It should not change native attachment pickers, attachment validation, PDF/image processing, upload APIs, or backend behavior. Normal silent updates should still happen when the user actually backgrounds the app or switches tabs outside of an active file picker.

What alternative solutions did you explore? (Optional)

I considered persisting the selected files through reload, but this flow passes browser File objects and callbacks through in-memory attachment context, which is not safely serializable into route params or storage. I also checked the multiple-file validation and attachment modal route, but those paths explain why the preview is lost after a reload, not why Safari reloads in the first place.

[melvin-bot]

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

[melvin-bot]

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

[oqildev]

Proposal

What is the root cause of that problem?

The "page reloads" is iOS Safari jettisoning the WebContent process under memory pressure, not a JS exception or a navigation bug. The trigger is that we decode and convert every picked file at once, in parallel, with no concurrency cap, right before the preview modal opens.

When you pick 3 files in the composer, onFilesValidated → validateFiles → validateAndResizeFiles runs in useFilesValidation.tsx. Each file is validated concurrently via Promise.all(files.map(...)), and validateAttachmentFile decodes each image to read its dimensions.

The expensive part is HEIC. Photos pulled from the iPhone Files app are HEIC, so each one hits the HEIC_OR_HEIF_IMAGE branch and lands in filesToConvert, which is then converted — again all at once — in useFilesValidation.tsx:210-214. Each convertHeicImage call fetches the full blob and decodes the full-resolution HEIC to a raw bitmap, then re-encodes it as JPEG (heicConverter/index.ts:43-55). A 12–48 MP iPhone photo is tens of MB as a decoded RGBA bitmap; three simultaneous decode+encode passes (plus the parallel resize in useFilesValidation.tsx:255) push a single Safari tab past the WKWebView memory budget. Safari kills and reloads the tab.

The modal "disappearing" is the expected downstream effect of that reload, not a second bug: the picked Files live only in an in-memory context, so after a reload useNavigateToReportOnRefresh sees no file and bounces the user back to the report (useNavigateToReportOnRefresh.ts:14-27). That hook only exists because the team already knows this flow can get the page reloaded out from under it.

This explains every axis of the report: iOS-Safari-only (tightest per-tab memory cap of any target), count-dependent (1 file is fine, 3 isn't), and reproducible in production (it's inherent to the parallel-decode path, not a recent regression).

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

Fix layer is the validation/processing hook (useFilesValidation.tsx) — the render/modal layer never runs, because the tab dies during pre-modal processing.

Bound the concurrency of the memory-heavy work so peak footprint doesn't scale with file count:

• Replace the unbounded Promise.all(filesToConvert.map(convertHeicImage)) at useFilesValidation.tsx:210-214 with sequential (or batch-of-1) processing, so only one HEIC bitmap is alive at a time. Same treatment for the resize pass at line 255 and, ideally, the initial validation map at line 173. A small runWithConcurrency(items, limit, fn) helper (limit 1 on web, or a higher cap elsewhere) keeps non-memory-constrained platforms fast.
• Make sure intermediate bitmaps/blobs are released between files — canvasFallback should null out / size-zero its canvas after toBlob, and we should URL.revokeObjectURL on any object URL we created for a file we end up discarding, so memory is reclaimed before the next file starts.

That alone should stop the eviction. The only edge case it touches is processing latency for large batches (sequential is slower wall-clock), which is already covered by the full-screen loader the hook shows during conversion/resize.

What alternative solutions did you explore? (Optional)

Treat it as the generic iOS-Safari "reload after returning from the file picker" quirk. Rejected: that quirk is count-independent and would break the single-file send too, but single-file works and the test specifically requires 3 files to repro. The count-dependence rules out the input-return path and points squarely at memory.

Suspect navigation serializing the Files/blob URLs into route state. Rejected: onFilesValidated stashes the file array in the in-memory reportAttachmentsContext and Navigation.navigate(REPORT_ADD_ATTACHMENT.getRoute(reportID)) only puts reportID in the route (useAttachmentPicker.ts:35-51) — nothing serializes the files, and a serialization failure would be platform-independent, not iOS-Safari-only.

Cap the number of selectable files lower than 30. Rejected as a fix — it's a band-aid that doesn't address the per-file memory cost (one huge photo could still evict), and it regresses the intended bulk-upload UX. Worth keeping only as a secondary guardrail if profiling shows a hard ceiling.

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @wildan-m Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.