Media: Show determinate GIF conversion progress in the upload snackbar

[adamsilverstein]

What?

Fixes #80325.

Shows determinate progress in the editor's upload progress snackbar while an animated GIF is being converted to a video: the snackbar's spinner is replaced with a determinate ProgressBar and the label switches from "Uploading" to "Processing". The block canvas is untouched - the image keeps its existing fade treatment.

Follows the direction in this review comment: an earlier iteration overlaid the progress bar on the Image block itself, which doesn't scale to small images and puts per-item processing UI on the block rather than in the shared upload surface.

Why?

Converting a long animated GIF to a video (#76942, #80072) can take tens of seconds: every frame is decoded and re-encoded via WebCodecs. #80260 fixed the outright hang, but during a legitimately long conversion the author only sees an indeterminate spinner with no indication of how far along the conversion is or whether it is making progress at all.

Exact progress is available for free: the conversion loop reads the total frame count up front (ImageDecoder track.frameCount) and processes frames one at a time, so framesDone / frameCount is precise. Encoder backpressure happens inside the same loop, so the frame index tracks wall-clock progress closely.

How?

Data layer:

• convertGifToVideo() in @wordpress/video-conversion accepts an optional onProgress callback reporting a 0–1 fraction. It is throttled to whole-percent increments so a thousand-frame GIF doesn't flood the worker message channel. The worker RPC layer (comctx) proxies top-level function arguments across the worker boundary, so the callback passes straight through.
• transcodeGifItem() in @wordpress/upload-media dispatches the previously dormant updateItemProgress() action from that callback. (QueueItem.progress, the UPDATE_PROGRESS reducer case, and getItemProgress() already existed with no producers or consumers.) Dispatches are additionally time-gated to one per 250ms: without this, a fast conversion emits ~100 reports in a couple of seconds and each dispatch synchronously re-renders every upload-store consumer in the editor, saturating the main thread so the browser never paints the bar. The final report always goes through.
• Progress is readable straight off the queue items returned by the existing getItems() selector; no new store API is added.

UI:

• UploadProgressSnackbar looks for a queue item reporting progress below 100 (the conversion runs on a sideload companion item, so the full queue is scanned rather than just the originals it counts). While one exists, the notice icon slot renders a determinate ProgressBar (from @wordpress/components) instead of the Spinner, and the label reads "Processing — file.gif" (with the usual "x of y" form for batches).
• The bar is styled for the snackbar's dark surface (white indicator via the --wp-components-color-foreground custom property, 4px tall, 48px wide) and the notice text is indented to clear the wider icon slot.
• Once conversion reaches 100% the snackbar falls back to the regular indeterminate "Uploading" state while the resulting video file uploads.

Out of scope: network upload progress for the resulting video file (apiFetch doesn't expose upload progress; for long GIFs the conversion phase dominates).

Testing Instructions

1. Ensure client-side media processing is active (it is on by default in the plugin).
2. In a Chromium-based browser, create a new post and upload a long animated GIF (a few hundred frames) to an Image block.
3. While the GIF is being converted, observe the upload snackbar switch from "Uploading — file.gif" (spinner) to "Processing — file.gif" with a determinate progress bar advancing in place of the spinner, then back to the regular flow ("Upload complete").
4. Short GIFs and regular images still show the spinner throughout (no progress is reported).

The states can also be reviewed in Storybook: Editor/UploadProgressSnackbar.

Unit tests:

npm run test:unit -- packages/editor/src/components/upload-progress-snackbar packages/video-conversion packages/upload-media

Note: there is no e2e assertion for the transient Processing state because conversion of the small e2e GIF fixtures completes in well under a second, which would make the assertion flaky. The data flow (worker progress reports, throttling, snackbar states) is covered by unit tests.

Screenshots

(Updated screenshot of the snackbar's Processing state incoming.)

[github-actions]

Size Change: +466 B (+0.01%)

Total Size: 7.65 MB

📦 View Changed

Filename	Size	Change
build/modules/video-conversion/worker.min.js	83.8 kB	+83 B (+0.1%)
build/scripts/editor/index.min.js	510 kB	+105 B (+0.02%)
build/scripts/upload-media/index.min.js	16.3 kB	+53 B (+0.33%)
build/styles/editor/style-rtl.css	31.6 kB	+56 B (+0.18%)
build/styles/editor/style-rtl.min.css	26.9 kB	+57 B (+0.21%)
build/styles/editor/style.css	31.6 kB	+58 B (+0.18%)
build/styles/editor/style.min.css	26.8 kB	+54 B (+0.2%)

_{compressed-size-action}

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in 2970d39.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29788532163
📝 Reported issues:

• [Flaky Test] should insert media, convert to blocks, and undo in one step #36123 in /test/e2e/specs/editor/blocks/classic.spec.js

[adamsilverstein]

@jasmussen - I tried moving the progress indicator to the snackbar in 2970d39: the block canvas is untouched now (the image keeps its existing fade), and UploadProgressSnackbar is determinate instead. While the conversion reports progress, the Spinner in the icon slot is swapped for a determinate ProgressBar and the label switches to "Processing — file.gif". Once conversion reaches 100% it falls back to the regular "Uploading" state while the resulting video file uploads.

Since progress now lives on the upload queue item itself (readable via getItems()), a future upload tray - or the media library - can render the same data; I removed the by-attachment selector the block overlay needed. The updated states are in Storybook under Editor/UploadProgressSnackbar.

Screenshots

[jasmussen]

Honestly that looks pretty good at a glance! Did you make the actual progressbar hairline thicker? It's intentionally 1.5px which is small but visible and elegant. If it's unchanged, IMO, this could work. I still think there's a larger vision we can unpack at a later time.

[adamsilverstein]

Honestly that looks pretty good at a glance! Did you make the actual progressbar hairline thicker? It's intentionally 1.5px which is small but visible and elegant. If it's unchanged, IMO, this could work. I still think there's a larger vision we can unpack at a later time.

The height is set explicitly in https://github.com/WordPress/gutenberg/pull/80329/changes#diff-96ffb1246440442d4d45343faaa6ee39c03d36f5757ee78124ad42a94e2abe51R28, I will try removing that height style to capture a screenshot of what it looks like without that.

[adamsilverstein]

Height removed:

I think thats about 2px vs 4 px?

now

previously

How does that look @jasmussen?

[jasmussen]

That looks perfect. In general for all our reused componentry, the less CSS we can add on top of it, the better, so it all looks the same across every instance! Nice.

[adamsilverstein]

Thanks for the reviews and approval @jasmussen. I'll leave this open a bit longer to get a code review as well, and I think we can land this before the next Beta.

[andrewserong]

I like the idea of a progress bar and when it displays I quite like the look of it, too. The main issue I've run into in testing is just that for the majority of smaller GIFs I upload the conversion stage is so quick it effectively looks like a flicker, rather than a good bit of visual feedback. I.e. in the following, the progress bar only shows for a frame or two:

2026-07-23.14.17.24.mp4

This is probably more of a design question, but if I'm wondering if we should stick with either the spinner or the progress bar, and not switch from spinner to progress bar to spinner?

I imagine the blocker to using a progress bar overall is that we then sort of need to bake in the overall progress across the entire upload sequence rather than just the GIF processing stage?

[ramonjd]

The main issue I've run into in testing is just that for the majority of smaller GIFs I upload the conversion stage is so quick it effectively looks like a flicker

Came to do some manual testing and I can't see the progress bar at all. I think I'm doing something wrong.

I understand there's an upper limit, but I tried:

• 35MB
• 25MB
• 21MB
• 15MB
• 6MB

GIFs, and all only show the upload snackbar, no progress indicator.

Kapture.2026-07-23.at.14.31.58.mp4

To confirm, I'm using latest Chrome running this branch freshly built. (also checked playground)

Here's one of the GIFs I'm using (5.7MB)

[adamsilverstein]

I like the idea of a progress bar and when it displays I quite like the look of it, too. The main issue I've run into in testing is just that for the majority of smaller GIFs I upload the conversion stage is so quick it effectively looks like a flicker, rather than a good bit of visual feedback. I.e. in the following, the progress bar only shows for a frame or two:

Ha its too fast now!

Came to do some manual testing and I can't see the progress bar at all. I think I'm doing something wrong.

@ramonjd Can you confirm the companion video is generated for you (you can watch for it sideloading in the network panel, check your uploads folder or check if you have an option to transform the gif to a video). Note that videos with transparency are not converted.

@andrewserong can you also confirm you are getting the conversion working?

[andrewserong]

@andrewserong can you also confirm you are getting the conversion working?

Yep, the videos are being converted to video for me, it's just that the processing stage for some of these test GIFs is so quick. As such, I'd probably suggest we take a look at this PR for 7.2 rather than 7.1 and see if we can have the progress bar contain the whole upload progress between conversion + file uploads etc, rather than switching between spinner + progress bar and back again.

One nuance there is that the server-side / non-client-side path will probably never be able to have an accurate progress bar since we don't have the same level of insights into what the real progress will be, so I imagine there'll still be a case where we want to sometimes show progress bar and sometimes a spinner.

What do you reckon? Does this change feel like a must have for 7.1?

[ramonjd]

Can you confirm the companion video is generated for you

Thanks for the help. I used a different gif from https://commons.wikimedia.org/wiki/Category:Animated_GIF_files_between_50_MP_and_100_MP and now I can reproduce what @andrewserong is experiencing. mp4 is being generated fine 👍🏻

This is a 15MB GIF:

Kapture.2026-07-24.at.13.02.49.mp4

[adamsilverstein]

What do you reckon? Does this change feel like a must have for 7.1?

Nope. For sure lets punt to 7.2.

I'm curious if you throttle your CPU (in the performance tab) can you get the progress bar to display? I think the optimization PRs just made it really efficient so maybe we don't even need this.

[adamsilverstein]

If we decide to enable Animated GIF sub-sizes, the processing time increases dramatically so we may want to show progress... but the indicator may be more of a "processing image X of Y" string vs a bar.

[andrewserong]

I'm curious if you throttle your CPU (in the performance tab) can you get the progress bar to display? I think the optimization PRs just made it really efficient so maybe we don't even need this.

Yeah, funnily enough CPU throttling (even by 20x) doesn't make much of a difference to the duration of when the progress bar is showing for me 🤷

If we decide to enable Animated GIF sub-sizes, the processing time increases dramatically so we may want to show progress... but the indicator may be more of a "processing image X of Y" string vs a bar.

Gotcha, yeah, sounds like a good thing to review all together when we pick up that work for 7.2 👍

[adamsilverstein]

Yeah, funnily enough CPU throttling (even by 20x) doesn't make much of a difference to the duration of when the progress bar is showing for me 🤷

Interesting... I'll give it another test!

[github-actions]

🤖 PR meta 🤖

📦 Bundle size

Size Change: +485 B (+0.01%)

Total Size: 8.21 MB

📦 View Changed

Filename	Size	Change
build/modules/video-conversion/worker.min.js	83.8 kB	+83 B (+0.1%)
build/scripts/editor/index.min.js	611 kB	+127 B (+0.02%)
build/scripts/upload-media/index.min.js	16.5 kB	+50 B (+0.3%)
build/styles/editor/style-rtl.css	32 kB	+57 B (+0.18%)
build/styles/editor/style-rtl.min.css	27.4 kB	+57 B (+0.21%)
build/styles/editor/style.css	32.1 kB	+56 B (+0.17%)
build/styles/editor/style.min.css	27.4 kB	+55 B (+0.2%)

_{58447a6 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	c437586	trunk	% Change
timeToFirstByte	55.55 ms +10.44% -3.15%	55.3 ms +11.21% -3.89%	0.45%
largestContentfulPaint	94 ms +8.51% -6.38%	90 ms +6.67% -2.22%	4.44%
lcpMinusTtfb	34.9 ms +21.2% -4.01%	33.2 ms +5.27% -5.42%	5.12%
wpBeforeTemplate	27.5 ms +14.91% -2%	27.22 ms +14% -2.31%	1.03%
wpTemplate	23.86 ms +5.66% -3.44%	23.84 ms +3.02% -4.7%	0.08%
wpTotal	51.41 ms +10.87% -2.72%	51.3 ms +10.9% -3.66%	0.21%
wpMemoryUsage	7.53 MB +0% -0%	7.49 MB +0% -0%	0.46%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	c437586	trunk	% Change
timeToFirstByte	45.3 ms +5.3% -2.43%	44.65 ms +5.38% -0.9%	1.46%
largestContentfulPaint	100 ms +4% -0%	98 ms +6.12% -2.04%	2.04%
lcpMinusTtfb	55.5 ms +0.99% -3.15%	53.15 ms +3.67% -2.63%	4.42%
wpBeforeTemplate	23.77 ms +5.22% -0.93%	23.84 ms +0.76% -1.89%	-0.29%
wpTemplate	17.79 ms +6.58% -1.97%	17.76 ms +2.48% -2.14%	0.17%
wpTotal	42.17 ms +5.12% -2.37%	41.55 ms +5.34% -1.3%	1.49%
wpMemoryUsage	6.15 MB +0% -0%	6.11 MB +0% -0%	0.58%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	c437586	trunk	% Change
mediaProcessingJpeg	411.48 ms +2.57% -1.45%	410.86 ms +1.78% -0.69%	0.15%
mediaProcessingAvif	6120.21 ms +0.29% -0.16%	6191.64 ms +0.08% -0.17%	-1.15%
mediaProcessingJpegToAvif	4280.81 ms +0.07% -0.11%	4306.91 ms +0.18% -0.01%	-0.61%

media-upload

Metric	c437586	trunk	% Change
jpegUploadProcessing	1458.82 ms +32.22% -2.18%	1425.27 ms +0.48% -1.2%	2.35%
pngUploadProcessing	201.11 ms +17.83% -2.02%	218.96 ms +8.38% -6.54%	-8.15%
largeJpegUploadProcessing	1399.75 ms +0.93% -0.43%	1401.26 ms +1.96% -0.61%	-0.11%
multipleImageUploadProcessing	1538.53 ms +1.27% -0.5%	1566.96 ms +8.66% -1.76%	-1.81%

post-editor

Metric	c437586	trunk	% Change
serverResponse	506.95 ms +4.75% -7.82%	488.86 ms +6.66% -8.14%	3.7%
firstPaint	240.41 ms +15.66% -16.4%	281.12 ms +34.13% -21.61%	-14.48%
domContentLoaded	1081.48 ms +0.71% -0.65%	1092.19 ms +1.11% -0.91%	-0.98%
loaded	1082.64 ms +0.73% -0.63%	1093.8 ms +1.07% -0.94%	-1.02%
firstContentfulPaint	445.93 ms +4.87% -3.98%	446.63 ms +2.59% -2.58%	-0.16%
firstBlock	3235.06 ms +0.76% -0.37%	3283.65 ms +1.05% -0.72%	-1.48%
type	21.75 ms +0.28% -2.71%	20.67 ms +1.11% -3.05%	5.22%
typeWithoutInspector	19.5 ms +1.23% -3.23%	20.6 ms +10.1% -4.27%	-5.34%
typeWithTopToolbar	23.75 ms +5.31% -4.38%	23.79 ms +5.76% -3.61%	-0.17%
typeContainer	8.94 ms +3.24% -5.93%	8.85 ms +8.25% -9.15%	1.02%
focus	73.64 ms +5.02% -6.98%	76.91 ms +1.77% -6.31%	-4.25%
firstFocus	210.75 ms +0% -0%	228.88 ms +0% -0%	-7.92%
selectAll	529.2 ms +5.06% -4.33%	534.16 ms +2.74% -1.64%	-0.93%
listViewOpen	74.15 ms +5.18% -9.22%	79.1 ms +2.17% -6.42%	-6.26%
inserterOpen	22.97 ms +7.66% -5.01%	24.94 ms +9.62% -11.63%	-7.9%
inserterHover	3.34 ms +3.59% -5.99%	3.36 ms +9.82% -7.74%	-0.6%
inserterSearch	8.19 ms +13.8% -16%	7.99 ms +11.26% -9.01%	2.5%
loadPatterns	640.36 ms +3.91% -2.3%	653.65 ms +4.49% -1.88%	-2.03%
wpTotal	496.76 ms +4.91% -7.96%	478.75 ms +6.91% -8.18%	3.76%
wpMemoryUsage	13.04 MB +0% -0%	13.01 MB +0% -0%	0.29%
wpDbQueries	54 +0% -1.85%	54 +0% -1.85%	0%

site-editor

Metric	c437586	trunk	% Change
serverResponse	336.53 ms +3.01% -4.89%	324.74 ms +4.26% -4.1%	3.63%
firstPaint	183.52 ms +86.36% -4.99%	176.62 ms +4.82% -8.61%	3.91%
domContentLoaded	835.17 ms +1.93% -1.46%	843.53 ms +0.65% -1.48%	-0.99%
loaded	836.08 ms +1.91% -1.46%	844.31 ms +0.66% -1.47%	-0.97%
firstContentfulPaint	342.2 ms +2.56% -2.05%	343.09 ms +2.88% -2.21%	-0.26%
firstBlock	3018.1 ms +2.83% -1.18%	3010.1 ms +0.13% -0.86%	0.27%
type	16.35 ms +5.08% -0.61%	16.77 ms +12.82% -4.53%	-2.5%
navigate	104.18 ms +3.54% -15.27%	111.64 ms +2.72% -4.79%	-6.68%
loadPatterns	1037 ms +15.76% -5.61%	1026.52 ms +10.93% -6.78%	1.02%
loadPages	1071.33 ms +2.8% -0.79%	1108.89 ms +0.78% -0.94%	-3.39%
wpTotal	328.06 ms +3.07% -5.05%	316.52 ms +4.3% -4.13%	3.65%
wpMemoryUsage	12.01 MB +0% -0%	11.97 MB +0% -0%	0.31%
wpDbQueries	43.5 +1.15% -1.15%	44 +0% -2.27%	-1.14%

_{58447a6 Run}

🏁 Flaky tests

Show the failures

Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

can use focal point picker to set the focal point of the cover image in /test/e2e/specs/editor/blocks/cover.spec.js, passed after 1 failed attempt.

Error: expect(locator).toHaveValue(expected) failed

Locator:  getByRole('group', { name: 'Focal point' }).getByRole('spinbutton', { name: 'Focal point left position' })
Expected: "20"
Received: "50"
Timeout:  5000ms

Call log:
  - Expect "toHaveValue" getByRole('group', { name: 'Focal point' }).getByRole('spinbutton', { name: 'Focal point left position' }) with timeout 5000ms
  - waiting for getByRole('group', { name: 'Focal point' }).getByRole('spinbutton', { name: 'Focal point left position' })
    14 × locator resolved to <input min="0" step="1" max="100" value="50" type="number" autocomplete="off" inputmode="numeric" id="inspector-input-control-2" aria-label="Focal point left position" class="components-input-control__input dde-cd-d-db-edeea-7njioi em5sgkm3"/>
       - unexpected value "50"

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/blocks/cover.spec.js:424:34

should update the URL from the last navigation if only varies in the URL fragment in /test/e2e/specs/interactivity/router-navigate.spec.ts, passed after 1 failed attempt.

Error: expect(locator).toHaveText(expected) failed

Locator:  getByTestId('title')
Expected: "Link 1"
Received: "Main"
Timeout:  5000ms

Call log:
  - Expect "toHaveText" getByTestId('title') with timeout 5000ms
  - waiting for getByTestId('title')
    14 × locator resolved to <h2 data-testid="title">Main</h2>
       - unexpected value "Main"

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/interactivity/router-navigate.spec.ts:160:25

_{58447a6 Run}

[adamsilverstein]

Closing this as not planned, we can tackle progress for other operations like gif->gif subsizes in a follow up.