Repository navigation
[Bug]: Large stored image attachments freeze scrolling while decoding #19922
Description
Before submitting
- Searched existing issues and PRs for image scrolling, decoding and attachment performance.
- Included a synthetic reproduction and measurements.
Area
apps/web
Steps to reproduce
- Start a disposable development instance at
42da166d131017335a1158d0b379dd68b8985796. - Use the reproduction scripts to create a synthetic conversation with 13 stored JPEG attachments, each 4590 × 8160 and about 6.37 MB.
- Open the image thread and scroll through the grid while the images first decode. The supplied browser script repeats cold decoding with fresh blob URLs for identical prefetched bytes, keeping network time out of the comparison.
This models older stored attachments. Current PNG/JPEG uploads are resized; the fixture does not claim that today's composer preserves these large originals.
Expected behavior
Scrolling should continue while large image attachments decode. Image pixels and expansion behavior should remain unchanged.
Actual behavior
The regular user attachment image uses default decoding. On Linux Chromium 154, three six-second cold-decoding runs each had a roughly 1,233 ms gap between animation frames. Setting the image's decoding hint to async reduced the longest gap to 167–250 ms. All 13 images loaded in each run.
| Before | Expected after / measured candidate |
|---|---|
| Cold image decoding can produce a contiguous ~1.23-second scroll freeze. | Let the browser paint other content while images decode; candidate worst pauses were 0.17–0.25 seconds. |
| Original images, same layout. | Preserve originals and layout. |
This is not a claim of perfect scrolling: shorter >50 ms delays increased in the async trials and p95 did not always improve. Warm-image scrolling was already smooth. Windows and macOS have not been tested.
Evidence
Before recording · Candidate recording · Raw unrecorded frame intervals
Recordings add overhead and are illustrative; the figures above come from separate unrecorded runs. The fixture contains only generated images and synthetic text.
Impact
Major degradation when viewing affected large stored attachments.
Version and environment
main @ 42da166d131017335a1158d0b379dd68b8985796; Linux, Chromium 154.0.0.0, 1280 × 800 viewport. Initially observed in Linux desktop conversation history; controlled reproduction uses the actual web timeline in the collaborative browser.
Activity
juliusmarminge commentedon Oct 15, 2026
Note
Grok responding on behalf of Julius.
Accepting this as a small performance bug. On current main, the user attachment
<img>inapps/web/src/components/chat/MessagesTimeline.tsx(the image grid button) has nodecodinghint, while the tool-activity icons in the same file already usedecoding="async". So the one-line change is consistent with what the file already does.Scope note: since #4967, large pasted images are compressed before upload, so this mainly affects older, large stored attachments, as you said. Your numbers come from Linux Chromium with a synthetic fixture. We haven't reproduced them ourselves.
Not a duplicate of the open perf trackers (#9661, #5626, #13925, #19220, #19163). Those cover other code paths.
The fix is proposed in #19923.