[Bug]: iOS: attaching a camera photo (HEIC) from the photo library freezes the composer; draft cannot be cancelled or removed, survives app relaunch #11427

Activity

1. juliusmarminge commented on Sep 12, 2026

   

   juliusmarminge

   on Sep 12, 2026

   Member

   More actions

   Triage

   Confirmed as a real iOS composer bug on App Store 1.1.0 (1d1bf5040) and still present on current main. Not a duplicate of #10361 (web), #9727 (persistence-only, held), #11265 (render mitigation on main only), or #7225 (provider HEIC rejection).

   The three stacked causes in the report check out against the code. One nuance on the “half-alive” height path is below; it does not change the diagnosis.

   What the code does

   1. Full-resolution re-encode through the bridge. pickComposerMedia in apps/mobile/src/lib/composerImages.ts still calls launchImageLibraryAsync({ base64: true, quality: 1 }) on both 1.1.0 and main. There is no max-edge downscale (web caps at 2048px in apps/web/src/lib/imageCompression.ts; mobile has no expo-image-manipulator equivalent). A 12 MP HEIC is decoded, re-encoded as JPEG at compression 1.0, then handed to JS as one multi-megabyte base64 string. The 10 MB gate (PROVIDER_SEND_TURN_MAX_IMAGE_BYTES) runs only after that. Oversized conversions are rejected with “exceeds the 10 MB attachment limit” and never attach — that is why some HEICs appear fine and others brick the composer.

   2. HEIC previews become the data URL. The picker returns JPEG magic (/9j/) while metadata is still image/heic. HEIC is not a supported send type, so the attachment is relabeled image/jpeg and gets previewUri: dataUrl because mimeType !== asset.mimeType. Tests in composerFiles.test.ts assert exactly that. PNG/GIF/WebP originals keep asset.uri as the preview — that is why a screenshot of the same photo attaches cleanly.

   On 1.1.0, ComposerAttachmentStrip renders <Image source={{ uri: previewUri }}> with that string. #11265 (merged 2026-09-12, not in the store build) added materializeDataUrlPreview and the comment describing the Fabric stall: a multi-megabyte data URL re-parsed on every layout pass starves JS/Fabric commits.

   That matches the half-alive composer: T3ComposerEditorView is a native UITextView and still accepts keystrokes. Send and the attachment remove button are JS Pressables. Composer expansion is also JS (isFocused → height: 36 collapsed vs minHeight: 72 / maxHeight: 160 expanded). Native onComposerContentSizeChange is emitted but not subscribed in the JS wrapper, so the stuck one-line height is the JS/Fabric layout path failing, not a missing native resize callback.

   #11265 on main avoids feeding the giant URL to <Image>. It does not remove the picker bridge stall, the inlined dataUrl on the attachment, persist/hydrate of that payload, or the missing cancel.

   3. The draft is persisted and re-hydrated. pickComposerMedia writes both dataUrl and previewUri. use-composer-drafts.ts JSON.stringifys the full draft document into composer-drafts/drafts.json after a 200 ms debounce and hydrates it on launch. The schema still requires fileUri or inline dataUrl; the comment on the image type is explicit that current writers still use inline bytes. Drafts are keyed per thread, so a fresh thread works while the stuck one reloads the same preview.

   There is no cancel while launchImageLibraryAsync / the size gate run (onPickDraftMedia in use-thread-composer-state.ts awaits the picker, then appends).

   Related work

   • Typing becomes slow with a very tall image attached to the composer #10361 — web composer: full-size preview + image bytes inlined in the persisted draft. Same family, different client.
   • perf(mobile): keep image bytes outside draft JSON #9727 (Theo, open, DO NOT MERGE; M5 in Track performance audit fixes #9661) — keep image bytes out of mobile draft JSON. Fixes item 3 and the relaunch re-freeze once a new native runtime ships. Does not fix item 1 or cancel.
   • feat: add inline file previews and attachment chips across surfaces #11265 (merged 2026-09-12) — materialize large data-URL previews to a cache file in the strip. Item 2 on main only; not in 1.1.0.
   • [Bug]: HEIC attachments are accepted then rejected by the provider - "Unsupported Claude image attachment type 'image/heic'" #7225 (closed) — HEIC rejected by the provider. Format acceptance only.

   Suggested fix

   1. Drop base64: true from the picker and read the file URI. Downscale to a 2048px max edge (match web) and re-encode at ~0.85 before the 10 MB gate, via expo-image-manipulator or the picker’s quality option.
   2. Never use a data URL as previewUri. Write a thumbnail file up front so persistence never holds a multi-megabyte string. feat: add inline file previews and attachment chips across surfaces #11265 is a render-side safety net, not a substitute.
   3. Show an in-progress attachment with cancel while pick/convert runs, and let remove work on a not-yet-ready item.

   Do not wait on #9727’s native-runtime hold for (1) or (3). Ship #11265 in the next store build as a partial mitigation of the post-import freeze.

   Workaround

   Screenshot the photo and attach the screenshot. The stuck draft is per thread, so a new thread should work. Force-quit is not enough: relaunch re-hydrates the same preview.

   Validation

   On a 12 MP+ camera HEIC (not a screenshot): attach from Photo Library; confirm import finishes quickly with a thumbnail; typing grows the editor; send and remove work; force-quit + relaunch does not re-freeze. Compare with a screenshot of the same photo and with a conversion that would have exceeded 10 MB at quality: 1.

   Severity: high (the affected draft is unusable; force-quit does not recover it).

   Accepting as bug.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 12, 2026
3. juliusmarminge

   closed this as completedin #11440on Sep 12, 2026