Fix: use converted JPEG for HEIC receipts on Submit share tab#96232
Fix: use converted JPEG for HEIC receipts on Submit share tab#96232MelvinBot wants to merge 3 commits into
Conversation
Co-authored-by: thelullabyy <thelullabyy@users.noreply.github.com>
…e tab Co-authored-by: thelullabyy <thelullabyy@users.noreply.github.com>
|
I looked into the failing checks. There's no code-level failure to fix — every functional check now passes:
The only red check is
That check just requires the checklist boxes in the PR description to be ticked and the To get this check green, |
|
@thelullabyy How is it looking, do you have ETA? |
|
@mountiny I was OOO yesterday, I will check it now. It can be ready for CME review EOD today |
|
@MelvinBot Please merge latest main |
…/App into claude-heicSubmitConvertedReceipt Co-authored-by: thelullabyy <thelullabyy@users.noreply.github.com>
|
🤖 Merged latest |
|
There's no code fix needed — every substantive check is green. I verified The only failing check is
This check just verifies that the PR Author Checklist boxes in the PR description are ticked. It's a human-completed checklist, so I can't (and shouldn't) fill it out on your behalf. Once you review and check off the items in the |
|
Please replace all |
|
@thelullabyy Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppScreen.Recording.2026-07-18.at.08.15.01.movAndroid: mWeb ChromeScreen.Recording.2026-07-18.at.08.17.19.moviOS: HybridAppScreen.Recording.2026-07-18.at.08.05.49.moviOS: mWeb SafariScreen.Recording.2026-07-18.at.08.09.11.movMacOS: Chrome / SafariScreen.Recording.2026-07-18.at.08.10.26.mov |
|
🤖 Done!
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d3a64ead6a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| // converted JPEG from VALIDATED_FILE_OBJECT; otherwise they fall back to the raw attachment. Re-deriving from | ||
| // currentAttachment here would discard the converted file (its content/mimeType are always set), uploading raw | ||
| // image/heic which the backend rejects. This mirrors ShareDetailsPage. | ||
| const sharedFileSource = fileUri; |
There was a problem hiding this comment.
Ensure the validated file belongs to the current share
For HEIC/image/* shares this now seeds the submit receipt from the global VALIDATED_FILE_OBJECT, but that Onyx value is not tied to the current SHARE_TEMP_FILE. ShareRootPage starts validation asynchronously and clearShareData() only nulls the key; an earlier share's conversion can still finish later and call addValidatedShareFile, leaving a stale JPEG here. In that window, the Submit tab can display/upload the previous share's converted file instead of the newly shared receipt, so please verify the validated file matches the current attachment (for example via its original id/source) before using it.
Useful? React with 👍 / 👎.
|
@MelvinBot Please add this test steps to PR description |
|
🤖 Done! Added the test steps to the Tests section of the PR description. |
Explanation of Change
On iOS, sharing a HEIC image into the app and using the Submit tab created the expense but failed to attach the receipt — the backend rejected it with
Unsupported file type: image/heic. The chat Share tab worked because it uploads the converted JPEG.SubmitDetailsPagealready computes the branch-awarefileUri/fileName/fileType, which resolve to the converted JPEG (fromVALIDATED_FILE_OBJECT) for shares that need conversion, and to the raw attachment otherwise. But it then re-derivedsharedFileSource/sharedFileName/sharedFileTypefromcurrentAttachmentwith?? fileUrifallbacks. SincecurrentAttachment.content/.mimeTypeare always populated for a shared file, those fallbacks were dead code and the raw.heicpath/image/heictype always won — flowing into the seeded receipt andperformUpload→readFileAsync.This change:
fileUri/fileName/fileTypedirectly for the receipt source/name/type, mirroringShareDetailsPage. Non-HEIC shares are unchanged (therefileUri === currentAttachment.content).performUploaduntil the async conversion has landed inVALIDATED_FILE_OBJECTfor shares that need validation (shouldUsePreValidatedFile && !validFilesToUpload), so a fast tap can't submit the raw file. The early return keeps clearingisConfirmingso the button isn't stuck and a retry succeeds once the JPEG is ready.Added regression tests in
tests/ui/SubmitDetailsPageTest.tsxcovering both the converted-upload behavior and the confirm guard.Fixed Issues
$ #95824
PROPOSAL: #95824 (comment)
Tests
Pre-requisites:
Offline tests
QA Steps
// TODO: These must be filled out, or the issue title must include "[No QA]."
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari