[$250] Receipt selected from gallery can upload as empty on iOS mobile web

[marcaaron]

Problem

On iOS mobile web (Chrome or Safari on iPhone), if a user selects a receipt photo from their gallery and briefly switches apps before submitting, the file can silently lose its content. The receipt appears to upload but arrives at the server as 0 bytes, showing the user "There was a problem creating the receipt."

Solution

Read the selected file into memory immediately after it's picked, before the user has a chance to background the app. iOS can revoke access to gallery-picked files after a short time, but files held in memory aren't affected.

Issue Owner

Current Issue Owner: @linhvovan29546

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022047114714909112922
• Upwork Job ID: 2047114714909112922
• Last Price Increase: 2026-04-23

[melvin-bot]

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

[melvin-bot]

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

[MelvinBot]

Proposal

What is the root cause of that problem?

On iOS mobile web, the AttachmentPicker onChange handler only creates a blob URL via URL.createObjectURL(file) and passes the raw File object reference forward. The file bytes are never read into memory at selection time — they're only accessed much later when the browser serializes FormData for the HTTP upload in prepareRequestPayload.

iOS Safari can revoke access to gallery-picked file references when the app is backgrounded, even briefly. When this happens the File object still exists but reads as 0 bytes, causing the server to receive an empty receipt.

The existing checkIfScanFileCanBeRead is reactive — it detects broken blob URLs on component re-mount but cannot prevent the problem.

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

Read the file into memory immediately after selection in the AttachmentPicker onChange handler. After getting e.target.files[0], use file.arrayBuffer() to read the bytes, then reconstruct a new File from that buffer: new File([arrayBuffer], file.name, { type: file.type, lastModified: file.lastModified }). This creates an in-memory file that iOS cannot revoke. Assign the blob URL to the new file and pass it to onPicked.

This should be guarded to only run on iOS mobile web (check the platform) to avoid unnecessary memory overhead on desktop browsers where the issue doesn't occur.

What alternative solutions did you explore? (Optional)

1. Fix in useFilesValidation — would only protect the receipt scan flow; doing it in AttachmentPicker protects all file attachment consumers.
2. Eagerly read using FileReader.readAsDataURL — produces a base64 string which is ~33% larger in memory than the raw ArrayBuffer approach.
3. Rely on checkIfScanFileCanBeRead — this is already too late; it detects the problem after the fact rather than preventing it.

---

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.

[marcaaron]

Here's a live example from today (2026-04-22, request 9f052cc3396f49ad-SJC):

iPhone, Chrome (CriOS), TrackExpense → 666

POST /api/TrackExpense
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 26_3_1 like Mac OS X)
            AppleWebKit/605.1.15 (KHTML, like Gecko)
            CriOS/142.0.7444.148 Mobile/15E148 Safari/604.1
HTTP status: 200  (outer nginx)
jsonCode: 666     (inner API — "There was a problem creating the receipt")

php-fpm for the same request

Retrived 0 bytes of file   (tag=api, end_point=/api.php)

[wildan-m]

Proposal

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

On iOS mobile web (Safari, Chrome, or any browser — they all share WebKit on iOS), when a user picks a receipt photo from the gallery and briefly switches apps before the upload completes, the file reaches the server with 0 bytes. The UI then shows "There was a problem creating the receipt." The user sees a file that looks selected in the app but whose contents have silently been replaced with emptiness.

What is the root cause of that problem?

A File returned by <input type="file"> on iOS WebKit is lazy — its bytes are not held in the JavaScript heap, they are fetched on demand from the iOS photo library when the object is finally read (e.g. when FormData serializes it for the upload request). iOS revokes that backing file access shortly after the browser process is backgrounded, so when the read finally happens after the user returns to the tab, the OS answers with zero bytes and WebKit surfaces that as a valid-but-empty file.

Today the web picker never reads the file up front. The change handler only wraps the lazy File in an object URL and hands it downstream:

App/src/components/AttachmentPicker/index.tsx

Lines 57 to 80 in 76f15c5

	onChange={(e) => {
	isPickingRef.current = false;
	if (!e.target.files) {
	return;
	}
	if (allowMultiple && e.target.files.length > 1) {
	const files = Array.from(e.target.files).map((currentFile) => {
	// eslint-disable-next-line no-param-reassign
	currentFile.uri = URL.createObjectURL(currentFile);
	return currentFile as FileObject;
	});
	onPicked.current(files);
	} else if (e.target.files[0]) {
	const file = e.target.files[0];
	file.uri = URL.createObjectURL(file);
	onPicked.current([file]);
	}
	// Cleanup after selecting a file to start from a fresh state
	if (fileInput.current) {
	fileInput.current.value = '';
	}
	}}

Because the actual byte read is deferred to upload time, anything that invalidates the backing between selection and upload (the user tapping away, the OS memory-reaping a background tab, a camera roll permission toggle) produces a 0-byte upload that the server cannot reject meaningfully — from the server's perspective it is just an empty file.

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

In the web AttachmentPicker change handler, materialize the selected file into a JS-owned buffer immediately upon selection, before returning control to the caller. Concretely:

1. In src/components/AttachmentPicker/index.tsx, convert the inline onChange handler to an async flow. For each picked File, await file.arrayBuffer() right away, then construct a new in-memory File wrapper from that buffer (preserving name, type, and lastModified). Use the new wrapper for URL.createObjectURL and for the value passed to onPicked. The downstream upload layer then consumes a JS-heap-backed file that iOS cannot revoke.

2. Gate the materialization on isMobileIOS() from @libs/Browser so only iOS mobile web pays the read cost — desktop/Android file inputs already return stable File objects, so rewrapping them would be pointless memory churn.

3. Apply the same treatment in the multi-file branch of the handler (the allowMultiple path) so attachments picked in bulk get the same protection.

The change is confined to this one file and keeps the public contract of the picker identical: callers still receive an array of FileObject with a uri string. The only observable difference is that the onPicked callback now fires a microtask later (after arrayBuffer() resolves), which is not user-visible because the user has not done anything yet.

The fix lives here:

App/src/components/AttachmentPicker/index.tsx

Lines 51 to 123 in 76f15c5

	return (
	<>
	<input
	hidden
	type="file"
	ref={fileInput}
	onChange={(e) => {
	isPickingRef.current = false;
	if (!e.target.files) {
	return;
	}
	if (allowMultiple && e.target.files.length > 1) {
	const files = Array.from(e.target.files).map((currentFile) => {
	// eslint-disable-next-line no-param-reassign
	currentFile.uri = URL.createObjectURL(currentFile);
	return currentFile as FileObject;
	});
	onPicked.current(files);
	} else if (e.target.files[0]) {
	const file = e.target.files[0];
	file.uri = URL.createObjectURL(file);
	onPicked.current([file]);
	}
	// Cleanup after selecting a file to start from a fresh state
	if (fileInput.current) {
	fileInput.current.value = '';
	}
	}}
	// We are stopping the event propagation because triggering the `click()` on the hidden input
	// causes the event to unexpectedly bubble up to anything wrapping this component e.g. Pressable
	onClick={(e) => {
	e.stopPropagation();
	if (!fileInput.current) {
	return;
	}
	fileInput.current.addEventListener(
	'cancel',
	() => {
	isPickingRef.current = false;
	// For Android Chrome, the cancel event happens before the page is visible on physical devices,
	// which makes it unreliable for us to show the keyboard, while on emulators it happens after the page is visible.
	// So here we can delay calling the onCanceled.current function based on visibility in order to reliably show the keyboard.
	if (Visibility.isVisible()) {
	onCanceled.current();
	return;
	}
	const unsubscribeVisibilityListener = Visibility.onVisibilityChange(() => {
	onCanceled.current();
	unsubscribeVisibilityListener();
	});
	},
	{once: true},
	);
	}}
	accept={acceptedFileTypes ? getAcceptableFileTypesFromAList(acceptedFileTypes) : getAcceptableFileTypes(type)}
	multiple={allowMultiple}
	/>
	{children({
	openPicker: ({onPicked: newOnPicked, onCanceled: newOnCanceled = () => {}}) => {
	if (isPickingRef.current) {
	return;
	}
	isPickingRef.current = true;
	onPicked.current = newOnPicked;
	fileInput.current?.click();
	onCanceled.current = newOnCanceled;
	},
	})}
	</>
	);
	}

And the platform helper we would guard on:

App/src/libs/Browser/index.website.ts

Lines 42 to 45 in 76f15c5

	const isMobileIOS: IsMobileIOS = () => {
	const userAgent = navigator.userAgent;
	return /iP(ad|od|hone)/i.test(userAgent);
	};

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88561-ios-gallery-receipt-empty-upload?expand=1

What alternative solutions did you explore? (Optional)

Validate file size at the boundary and retry-with-re-pick on 0 bytes. We could check file.size (or read the bytes) right before building the upload FormData and, on a 0-byte read, prompt the user to re-select. This is reactive rather than preventive — the user has already lost their work and must repeat the pick. It also does not help flows where the upload is kicked off from a different tab/screen than the one that picked the file.

Force a synchronous read of the first byte on pick. Touching the file (e.g. file.slice(0, 1).arrayBuffer()) might nudge iOS into materializing the handle while the foreground is still alive. In testing this is unreliable: WebKit still holds a reference to the gallery source, and the revocation after backgrounding still empties subsequent full reads. Reading all bytes up front is the only robust guarantee.

Apply the same materialization in src/components/FilePicker/index.tsx. FilePicker has the same shape and the same latent risk, but its real-world use (spreadsheet imports, doc attachments) goes through the iOS Files app, whose backing is more stable than Photos. It is worth doing eventually, but scoping the change to the picker path that actually produces the reported repro keeps this fix small and reviewable.

[15antonian]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @15antonian 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.