Media: Detect HEIC uploads from the file header rather than the file name

[adamsilverstein]

What?

Detect HEIC uploads from the file's own header instead of from its name or the MIME type the browser reports, so a HEIC photo saved with a .jpg or .png extension, or one the operating system cannot type at all, converts like any other HEIC file. Also bound the ImageDecoder decode with a timeout so a decoder that never settles cannot hang the upload.

Fixes #81707
Fixes #81043

Supersedes #81211 by @singhakanshu00, whose timeout commit is carried here under their authorship. The header check in that PR came out of @t-hamano's review there and is generalized in this one.

Why?

A browser derives File.type from the file extension alone, and both places that route an upload went by that type:

• prepareItem() in packages/upload-media/src/store/private-actions.ts treated a misnamed file as a JPEG/PNG, so it took the vips path. vips cannot decode HEIC, and the upload wound up stuck: the progress snackbar sat at "Uploading" and never completed or reported a failure. An attachment was still created, and WordPress renamed and re-encoded the file server side behind the editor's back.
• The same routing saw an empty File.type, which is what Windows without the HEVC extension reports for a .heic file (confirmed by @369work and @t-hamano in HEIC upload hangs indefinitely instead of falling back to server-side processing #81043), as "not an image" and uploaded the raw bytes as-is to a server that could not convert them either.
• heicMediaUpload() in packages/block-editor/src/components/provider/index.jsx (the HEIC-only canvas mode used in Safari) sorted the batch by the same type, so a misnamed or untyped file was handed to the server-side path.

Both paths now ask the file what it is. WordPress core already does this server side in wp_get_image_mime(), which reads the ISOBMFF File Type Box for exactly this reason.

Separately, ImageDecoder.isTypeSupported() can report HEIC support from the container format alone. When the platform codec behind it is missing, decode() never settles rather than rejecting, and nothing downstream ever runs. Nobody has caught this in the wild yet, but relabelling an untyped file as image/heic is what lets that strategy run at all for the Windows case, so the guard belongs in the same change.

How?

• New isHeicFile() export in @wordpress/upload-media. It trusts a HEIC MIME type when there is one, otherwise reads the first 64 bytes and checks the File Type Box brands. AVIF shares the HEIF container and declares mif1 too, so the AVIF brands are ruled out first. Only files that could plausibly be images are read, so an ISOBMFF video is never mistaken for a still.
• prepareItem() uses it for isHeic, and keeps isVipsSupported false for anything HEIC by content.
• A misnamed or untyped file is re-labelled image/heic before conversion. The WebCodecs decoder is configured from File.type, and the untouched original is sideloaded as the attachment's source_original companion under its own name.
• heicMediaUpload() partitions the batch with the same helper.
• In canvasConvertToJpeg(), the ImageDecoder decode is raced against a 15 second timeout that closes the decoder, which rejects the pending call. Only a timed-out decode falls through to the next strategy; a decode that rejects on its own has read the file and found it damaged, and Client side media: improve HEIC error message and consider placing inside image block #81123 reports that as a processing error rather than blaming the codec. The ceiling is generous because it applies to every decode, not only a stalled one.

Testing Instructions

Client-side media processing has to be active - check window.__clientSideMediaProcessing in the console.

Wrong extension (#81707):

1. Take any .heic photo and rename it to .jpg. The test asset in this PR is one: test/e2e/assets/450x600_e2e_test_image_heic_wrong_extension.jpg.
2. Upload it into an Image block.
3. Where the browser can decode HEIC - Safari, or Chrome on macOS through VideoToolbox - it converts to a JPEG and uploads, same as the correctly named file.
4. Where it cannot - Firefox, or Chrome on Linux - it reports "couldn't decode HEIC" instead of hanging.

Either way the result now matches what the same photo does with its real .heic extension, which is the point. On trunk, Safari quietly falls back to a server-side upload, and a browser that cannot decode HEIC leaves the "Uploading" snackbar spinning forever.

Untyped file (#81043):

1. On Windows without the HEVC Video Extension, drop a .heic file onto an Image block. With the codecs installed it should convert; without them it should report "couldn't decode HEIC" after a moment rather than spinning forever. This is the environment the fix has not been run in yet, so a real Windows test would be very welcome.
2. Anywhere else, simulate the empty type from the console before dropping a file: wrap the file as new File( [ original ], original.name, { type: '' } ) and dispatch it with wp.data.dispatch( 'core/upload-media' ).addItems( ... ), as @singhakanshu00 did on fix: Fixes HEIC uploads hanging indefinitely when ImageDecoder stalls #81211.

Stalled decoder: paste the StuckImageDecoder shim from the #81211 description into the console before uploading a .heic. On trunk the spinner never stops; here it moves on after 15 seconds.

Automated coverage:

npm run test:unit:vitest -- packages/upload-media
cd test/e2e && npx playwright test --project=chromium specs/editor/various/heic-wrong-extension.spec.js

Two e2e tests, one per routing site: the first in the default full client-side mode, the second with cross-origin isolation disabled so the editor falls into the HEIC-only canvas mode Safari uses. Both were confirmed failing before the corresponding fix and passing after - the second one still passes on trunk's prepareItem() fix alone, which is what makes the provider half worth covering separately.

Both run in Chromium deliberately. Chromium ships no HEVC codec, so the HEIC path always ends at the same decode error, and reaching that path is the thing under test. An earlier version of this spec asserted a successful conversion in WebKit; that passes on macOS, where the OS supplies the codec, and crashes the page on Linux CI.

Unit tests cover the header check for both the wrong-extension and empty-type cases, prepareItem() routing for both, a decode that never settles (fake timers), and a canvas failure after a successful decode staying a processing error rather than falling through.

Types of changes

Bug fix.

• Add isHeicFile() to @wordpress/upload-media.
• Route prepareItem() and heicMediaUpload() by file content rather than by File.type.
• Re-label a misnamed or untyped HEIC before conversion and sideload.
• Bound the ImageDecoder decode with a timeout, falling through only on timeout.
• Add unit tests for the header check, the routing, and the decoder, plus an e2e spec covering both browser paths.

AI Use

Code and description both written with 🤖 Claude Code, apart from the timeout commit by @singhakanshu00. I will review and test.

[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: singhakanshu00 <akanshusingh@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: 369work <369work@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: pbiron <pbiron@git.wordpress.org>
Co-authored-by: aaronjorbin <jorbin@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]

Size Change: +261 B (0%)

Total Size: 7.91 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	477 kB	+22 B (0%)
build/scripts/upload-media/index.min.js	16.5 kB	+239 B (+1.47%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 7d3b7a6.
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/33113926971
📝 Reported tests:

refuses the drop and uploads nothing in /test/e2e/specs/editor/various/single-file-placeholder-drop.spec.js, passed after 1 failed attempt.

Error: expect(received).toHaveLength(expected)

Expected length: 0
Received length: 2
Received array:  [{"_links": {"about": [{"href": "http://localhost:8889/wp-json/wp/v2/types/attachment"}], "author": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/users/1"}], "collection": [{"href": "http://localhost:8889/wp-json/wp/v2/media"}], "replies": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/comments?post=119"}], "self": [{"href": "http://localhost:8889/wp-json/wp/v2/media/119", "targetHints": {"allow": ["GET", "POST", "PUT", "PATCH", "DELETE"]}}]}, "alt_text": "", "author": 1, "caption": {"rendered": ""}, "class_list": ["post-119", "attachment", "type-attachment", "status-inherit", "hentry", "entry"], "comment_status": "open", "date": "2026-08-27T20:45:39", "date_gmt": "2026-08-27T20:45:39", "description": {"rendered": "<p class=\"attachment\"><a href='http://localhost:8889/wp-content/uploads/2026/08/10x10_e2e_test_image_z9T8jK-1.png'><img loading=\"lazy\" decoding=\"async\" width=\"10\" height=\"10\" src=\"http://localhost:8889/wp-content/uploads/2026/08/10x10_e2e_test_image_z9T8jK-1.png\" class=\"attachment-medium size-medium\" alt=\"\" style=\"width:100%;height:100%;max-width:10px;\" /></a></p>
"}, "featured_media": 0, "filename": "10x10_e2e_test_image_z9T8jK-1.png", "filesize": 80, "guid": {"rendered": "http://localhost:8889/wp-content/uploads/2026/08/10x10_e2e_test_image_z9T8jK-1.png"}, "id": 119, "link": "http://localhost:8889/10x10_e2e_test_image_z9t8jk-2/", "media_details": {"file": "2026/08/10x10_e2e_test_image_z9T8jK-1.png", "filesize": 80, "height": 10, "image_meta": {"alt": "", "aperture": "0", "camera": "", "caption": "", "copyright": "", "created_timestamp": "0", "credit": "", "focal_length": "0", "iso": "0", "keywords": [], "orientation": "0", "shutter_speed": "0", "title": ""}, "sizes": {}, "width": 10}, "media_type": "image", "meta": [], "mime_type": "image/png", "modified": "2026-08-27T20:45:39", "modified_gmt": "2026-08-27T20:45:39", "ping_status": "closed", "post": null, "slug": "10x10_e2e_test_image_z9t8jk-2", "source_url": "http://localhost:8889/wp-content/uploads/2026/08/10x10_e2e_test_image_z9T8jK-1.png", "status": "inherit", "template": "", "title": {"rendered": "10x10_e2e_test_image_z9T8jK"}, "type": "attachment"}, {"_links": {"about": [{"href": "http://localhost:8889/wp-json/wp/v2/types/attachment"}], "author": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/users/1"}], "collection": [{"href": "http://localhost:8889/wp-json/wp/v2/media"}], "replies": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/comments?post=115"}], "self": [{"href": "http://localhost:8889/wp-json/wp/v2/media/115", "targetHints": {"allow": ["GET", "POST", "PUT", "PATCH", "DELETE"]}}]}, "alt_text": "", "author": 1, "caption": {"rendered": ""}, "class_list": ["post-115", "attachment", "type-attachment", "status-inherit", "hentry", "entry"], "comment_status": "open", "date": "2026-08-27T20:45:20", "date_gmt": "2026-08-27T20:45:20", "description": {"rendered": "<p class=\"attachment\"><a href='http://localhost:8889/wp-content/uploads/2026/08/10x10_e2e_test_image_z9T8jK.png'><img loading=\"lazy\" decoding=\"async\" width=\"10\" height=\"10\" src=\"http://localhost:8889/wp-content/uploads/2026/08/10x10_e2e_test_image_z9T8jK.png\" class=\"attachment-medium size-medium\" alt=\"\" style=\"width:100%;height:100%;max-width:10px;\" /></a></p>
"}, "featured_media": 0, "filename": "10x10_e2e_test_image_z9T8jK.png", "filesize": 80, "guid": {"rendered": "http://localhost:8889/wp-content/uploads/2026/08/10x10_e2e_test_image_z9T8jK.png"}, "id": 115, "link": "http://localhost:8889/10x10_e2e_test_image_z9t8jk/", "media_details": {"file": "2026/08/10x10_e2e_test_image_z9T8jK.png", "filesize": 80, "height": 10, "image_meta": {"alt": "", "aperture": "0", "camera": "", "caption": "", "copyright": "", "created_timestamp": "0", "credit": "", "focal_length": "0", "iso": "0", "keywords": [], "orientation": "0", "shutter_speed": "0", "title": ""}, "sizes": {}, "width": 10}, "media_type": "image", "meta": [], "mime_type": "image/png", "modified": "2026-08-27T20:45:20", "modified_gmt": "2026-08-27T20:45:20", "ping_status": "closed", "post": null, "slug": "10x10_e2e_test_image_z9t8jk", "source_url": "http://localhost:8889/wp-content/uploads/2026/08/10x10_e2e_test_image_z9T8jK.png", "status": "inherit", "template": "", "title": {"rendered": "10x10_e2e_test_image_z9T8jK"}, "type": "attachment"}]
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/single-file-placeholder-drop.spec.js:71:45

[github-actions]

🤖 PR meta 🤖

📦 Bundle size

Size Change: +321 B (0%)

Total Size: 8.21 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	499 kB	-29 B (-0.01%)
build/scripts/upload-media/index.min.js	16.8 kB	+350 B (+2.12%)

_{d9be887 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	4788f68	trunk	% Change
timeToFirstByte	57.5 ms +10.43% -3.83%	58.05 ms +11.63% -4.82%	-0.95%
largestContentfulPaint	94 ms +10.64% -4.26%	96 ms +6.25% -8.33%	-2.08%
lcpMinusTtfb	35.15 ms +26.32% -5.41%	35.1 ms +4.56% -3.56%	0.14%
wpBeforeTemplate	28.7 ms +16.24% -3.45%	27.95 ms +21.32% -1.61%	2.68%
wpTemplate	24.22 ms +2.93% -3.34%	24.56 ms +2.77% -4.85%	-1.38%
wpTotal	52.91 ms +12.11% -2.78%	54.29 ms +9.87% -4.97%	-2.54%
wpMemoryUsage	7.59 MB +0% -0%	7.55 MB +0% -0%	0.45%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	4788f68	trunk	% Change
timeToFirstByte	42.9 ms +13.87% -2.1%	43.25 ms +7.4% -2.66%	-0.81%
largestContentfulPaint	96 ms +2.08% -8.33%	92 ms +4.35% -4.35%	4.35%
lcpMinusTtfb	48.2 ms +4.77% -3.53%	47.15 ms +3.92% -2.01%	2.23%
wpBeforeTemplate	26.17 ms +18.8% -2.1%	26.11 ms +11.91% -1.19%	0.23%
wpTemplate	13.83 ms +6.58% -1.66%	13.56 ms +6.78% -1.33%	1.99%
wpTotal	40.13 ms +14.3% -2.34%	40.38 ms +6.88% -2.45%	-0.62%
wpMemoryUsage	6.07 MB +0% -0%	6.03 MB +0% -0%	0.58%
wpDbQueries	10 +0% -0%	10 +0% -0%	0%

media-processing

Metric	4788f68	trunk	% Change
mediaProcessingJpeg	396.48 ms +0.55% -1.56%	395.37 ms +2.74% -0.26%	0.28%
mediaProcessingAvif	6056.81 ms +0.15% -0.13%	6040.58 ms +0.1% -0.22%	0.27%
mediaProcessingJpegToAvif	4179.36 ms +0.17% -0.26%	4176.23 ms +0.15% -0.1%	0.07%

media-upload

Metric	4788f68	trunk	% Change
jpegUploadProcessing	1487.01 ms +30.37% -4.37%	1425.35 ms +1.03% -1.1%	4.33%
pngUploadProcessing	176.72 ms +24.56% -2.91%	221.84 ms +4.85% -8.16%	-20.34%
largeJpegUploadProcessing	1414 ms +0.58% -0.74%	1406.95 ms +0.48% -0.26%	0.5%
multipleImageUploadProcessing	1598.55 ms +11.51% -2.56%	1572.39 ms +1.02% -2.02%	1.66%

post-editor

Metric	4788f68	trunk	% Change
serverResponse	386.02 ms +9.33% -1.5%	428.34 ms +4.67% -4.77%	-9.88%
firstPaint	207.05 ms +18.3% -8.3%	174.39 ms +30.51% -10.92%	18.73%
domContentLoaded	1100.41 ms +2.25% -2.34%	1112.28 ms +0.99% -1.21%	-1.07%
loaded	1101.76 ms +2.24% -2.34%	1113.52 ms +1.02% -1.21%	-1.06%
firstContentfulPaint	442.68 ms +5.13% -1.98%	460.39 ms +1.26% -5.77%	-3.85%
firstBlock	3189.38 ms +1.6% -1.79%	3229.07 ms +0.28% -0.49%	-1.23%
type	20.99 ms +2.48% -1.72%	21.81 ms +4.22% -4.31%	-3.76%
typeWithoutInspector	20.1 ms +3.43% -1.09%	21.13 ms +6.06% -1.56%	-4.87%
typeWithTopToolbar	26.23 ms +7.85% -4.61%	29.16 ms +3.98% -7.51%	-10.05%
typeContainer	8.97 ms +5.8% -5.57%	9.37 ms +12.7% -7.9%	-4.27%
focus	74.76 ms +2.9% -3.58%	77.05 ms +4.02% -2.91%	-2.97%
firstFocus	196.3 ms +0% -0%	233.87 ms +0% -0%	-16.06%
selectAll	520.25 ms +0.89% -3.9%	518.02 ms +0.18% -4.72%	0.43%
listViewOpen	76.24 ms +10.77% -5.54%	77.35 ms +2.38% -6.49%	-1.44%
inserterOpen	24.88 ms +4.22% -4.42%	24.66 ms +12.29% -10.83%	0.89%
inserterHover	3.42 ms +7.31% -9.94%	3.27 ms +19.88% -4.89%	4.59%
inserterSearch	8.35 ms +9.82% -3.11%	9.04 ms +3.87% -8.41%	-7.63%
loadPatterns	671.99 ms +2.17% -4.87%	660.55 ms +2.46% -1.01%	1.73%
wpTotal	374.88 ms +9.57% -1.62%	416.97 ms +4.83% -4.85%	-10.09%
wpMemoryUsage	13.13 MB +0% -0%	13.09 MB +0% -0%	0.28%
wpDbQueries	54 +0% -1.85%	54 +0% -0%	0%

site-editor

Metric	4788f68	trunk	% Change
serverResponse	407.38 ms +1.49% -8.01%	409.7 ms +2.23% -3.07%	-0.57%
firstPaint	281.42 ms +19.35% -29.92%	243.78 ms +82.16% -10.6%	15.44%
domContentLoaded	1124.29 ms +2.82% -2.43%	1114.49 ms +0.83% -1.79%	0.88%
loaded	1125.48 ms +2.82% -2.44%	1115.63 ms +0.84% -1.78%	0.88%
firstContentfulPaint	447.71 ms +2.6% -1.02%	456.25 ms +2.47% -1.56%	-1.87%
firstBlock	3952.34 ms +2.94% -0.83%	3960.74 ms +1.05% -1.62%	-0.21%
type	19.7 ms +1.52% -3.05%	20.43 ms +1.66% -3.43%	-3.57%
navigate	98.88 ms +8.16% -1.59%	118.84 ms +3.06% -8.28%	-16.8%
loadPatterns	1265.93 ms +21.82% -7.38%	1274.39 ms +10.68% -5.76%	-0.66%
loadPages	1103.17 ms +0.23% -0.26%	1114.87 ms +2.15% -1.55%	-1.05%
wpTotal	396.88 ms +1.46% -8.39%	397.88 ms +2.62% -2.83%	-0.25%
wpMemoryUsage	12.10 MB +0% -0%	12.05 MB +0% -0%	0.4%
wpDbQueries	43.5 +1.15% -1.15%	43.5 +1.15% -1.15%	0%

_{d9be887 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.

refuses the drop and uploads nothing in /test/e2e/specs/editor/various/single-file-placeholder-drop.spec.js, passed after 1 failed attempt.

Error: expect(received).toHaveLength(expected)

Expected length: 0
Received length: 2
Received array:  [{"_links": {"about": [{"href": "http://localhost:8889/wp-json/wp/v2/types/attachment"}], "author": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/users/1"}], "collection": [{"href": "http://localhost:8889/wp-json/wp/v2/media"}], "curies": [{"href": "https://api.w.org/{rel}", "name": "wp", "templated": true}], "replies": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/comments?post=241"}], "self": [{"href": "http://localhost:8889/wp-json/wp/v2/media/241", "targetHints": {"allow": ["GET", "POST", "PUT", "PATCH", "DELETE"]}}], "wp:attached-to": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/posts/239", "id": 239, "post_type": "post"}]}, "alt_text": "", "author": 1, "caption": {"rendered": ""}, "class_list": ["post-241", "attachment", "type-attachment", "status-inherit", "hentry", "entry"], "comment_status": "open", "date": "2026-09-22T10:42:01", "date_gmt": "2026-09-22T10:42:01", "description": {"rendered": "<p class=\"attachment\"><a href='http://localhost:8889/wp-content/uploads/2026/09/10x10_e2e_test_image_z9T8jK-1.png'><img loading=\"lazy\" decoding=\"async\" width=\"10\" height=\"10\" src=\"http://localhost:8889/wp-content/uploads/2026/09/10x10_e2e_test_image_z9T8jK-1.png\" class=\"attachment-medium size-medium\" alt=\"\" style=\"width:100%;height:100%;max-width:10px;\" /></a></p>
"}, "featured_media": 0, "filename": "10x10_e2e_test_image_z9T8jK-1.png", "filesize": 80, "guid": {"rendered": "http://localhost:8889/wp-content/uploads/2026/09/10x10_e2e_test_image_z9T8jK-1.png"}, "id": 241, "link": "http://localhost:8889/?attachment_id=241", "media_details": {"file": "2026/09/10x10_e2e_test_image_z9T8jK-1.png", "filesize": 80, "height": 10, "image_meta": {"alt": "", "aperture": "0", "camera": "", "caption": "", "copyright": "", "created_timestamp": "0", "credit": "", "focal_length": "0", "iso": "0", "keywords": [], "orientation": "0", "shutter_speed": "0", "title": ""}, "sizes": {}, "width": 10}, "media_type": "image", "meta": [], "mime_type": "image/png", "modified": "2026-09-22T10:42:01", "modified_gmt": "2026-09-22T10:42:01", "ping_status": "closed", "post": 239, "slug": "10x10_e2e_test_image_z9t8jk-2", "source_url": "http://localhost:8889/wp-content/uploads/2026/09/10x10_e2e_test_image_z9T8jK-1.png", "status": "inherit", "template": "", "title": {"rendered": "10x10_e2e_test_image_z9T8jK"}, "type": "attachment"}, {"_links": {"about": [{"href": "http://localhost:8889/wp-json/wp/v2/types/attachment"}], "author": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/users/1"}], "collection": [{"href": "http://localhost:8889/wp-json/wp/v2/media"}], "curies": [{"href": "https://api.w.org/{rel}", "name": "wp", "templated": true}], "replies": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/comments?post=240"}], "self": [{"href": "http://localhost:8889/wp-json/wp/v2/media/240", "targetHints": {"allow": ["GET", "POST", "PUT", "PATCH", "DELETE"]}}], "wp:attached-to": [{"embeddable": true, "href": "http://localhost:8889/wp-json/wp/v2/posts/239", "id": 239, "post_type": "post"}]}, "alt_text": "", "author": 1, "caption": {"rendered": ""}, "class_list": ["post-240", "attachment", "type-attachment", "status-inherit", "hentry", "entry"], "comment_status": "open", "date": "2026-09-22T10:42:01", "date_gmt": "2026-09-22T10:42:01", "description": {"rendered": "<p class=\"attachment\"><a href='http://localhost:8889/wp-content/uploads/2026/09/10x10_e2e_test_image_z9T8jK.png'><img loading=\"lazy\" decoding=\"async\" width=\"10\" height=\"10\" src=\"http://localhost:8889/wp-content/uploads/2026/09/10x10_e2e_test_image_z9T8jK.png\" class=\"attachment-medium size-medium\" alt=\"\" style=\"width:100%;height:100%;max-width:10px;\" /></a></p>
"}, "featured_media": 0, "filename": "10x10_e2e_test_image_z9T8jK.png", "filesize": 80, "guid": {"rendered": "http://localhost:8889/wp-content/uploads/2026/09/10x10_e2e_test_image_z9T8jK.png"}, "id": 240, "link": "http://localhost:8889/?attachment_id=240", "media_details": {"file": "2026/09/10x10_e2e_test_image_z9T8jK.png", "filesize": 80, "height": 10, "image_meta": {"alt": "", "aperture": "0", "camera": "", "caption": "", "copyright": "", "created_timestamp": "0", "credit": "", "focal_length": "0", "iso": "0", "keywords": [], "orientation": "0", "shutter_speed": "0", "title": ""}, "sizes": {}, "width": 10}, "media_type": "image", "meta": [], "mime_type": "image/png", "modified": "2026-09-22T10:42:01", "modified_gmt": "2026-09-22T10:42:01", "ping_status": "closed", "post": 239, "slug": "10x10_e2e_test_image_z9t8jk", "source_url": "http://localhost:8889/wp-content/uploads/2026/09/10x10_e2e_test_image_z9T8jK.png", "status": "inherit", "template": "", "title": {"rendered": "10x10_e2e_test_image_z9T8jK"}, "type": "attachment"}]
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/single-file-placeholder-drop.spec.js:71:45

_{d9be887 Run}

[adamsilverstein]

Following up on the question from @t-hamano over on #81211 about which PR to review: this one now covers both issues, so this is the one to review.

I had Claude compare the two branches and fold them together, here is the summary:

The header check in the two PRs was the same idea with different gates: #81211 sniffed the File Type Box only when file.type was empty, this branch sniffs whenever the declared type leaves the question open, which covers the empty type and the wrong extension both. The two isHeicBuffer() helpers were near identical, so nothing from that side needed carrying over.

The one thing #81211 had that this branch did not was the ImageDecoder timeout. That is now here as @singhakanshu00's own commit (66c4e0b), with a follow-up on top (a10c5de) that narrows it: only a decode that times out falls through to the next strategy. A decode that rejects on its own has read the file and found it damaged, and #81123 wants that reported as a processing error, not blamed on the codec. The broad catch in #81211 actually fails that existing test on trunk, which is worth knowing if anyone was planning to rebase it. The ceiling also went from 3 to 15 seconds, since the race cuts off every decode and not only a stalled one.

Also added: a prepareItem() unit test for a file with an empty type, mirroring the wrong-extension one, and two canvasConvertToJpeg() tests for the stalled decode and the canvas failure after a good decode. The full upload-media suite passes locally, 405 tests.

One caveat: none of this has run on real Windows without the HEVC extension, which is the #81043 environment. The unit test covers the routing, and the expected behavior is what @369work and @pbiron already saw with the #81211 build - a clean "couldn't decode HEIC" without the codecs, a conversion with them - but a real test there is the confirmation that matters.

@369work @pbiron whenever you have a chance, could you try the build from this PR on your Windows setups the same way you tested #81211? A drop onto an Image block is the path to check.

cc: @t-hamano @singhakanshu00

[369work]

== Test Report

Patch tested: #81737

=== Environment

• WordPress: 7.1
• Subdirectory: No
• PHP: 8.4.24
• Server: PHP/8.4.24 (Development Server)
• Database: WP_MySQL_On_SQLite (Server: 8.0.38 / Client: 3.53.2)
• Browser: Chrome 153.0.0.0
• OS: Windows 11
• Theme: Twenty Twenty-Five 1.5
• MU Plugins:
  • 99-studio-loader.php
• Plugins:
  • Gutenberg 24.0.0 (build from this PR)
  • Query Monitor 4.0.7
  • Test Reports 1.3.1

Store extensions visible in the installed apps list:

• HEVC Video Extensions
• Web Media Extensions

HEIF Image Extensions did not appear in that list, but the Photos app opens HEIC files normally, so
something on this system handles them. I have not established which component that is.

=== Steps taken

1. Installed the plugin build from this PR (reports as Gutenberg 24.0.0), then started the site in WordPress Studio. The patch was in place throughout -I did not test the unpatched build (trunk) for comparison in this round.
2. Opened a new post, added an Image block, and dropped IMG_1250.HEIC onto it.

Logged in the console as the file was dropped:

[observed] name=IMG_1250.HEIC  type=''  size=1316390
[observed] isTypeSupported(image/heic) = false

Also checked in the console:

• window.__clientSideMediaProcessing - true
• window.crossOriginIsolated - true
• SharedArrayBuffer - available
• File header brands - ftyp + heic / mif1 / miaf, no AVIF brands

x. ✅ Patch is solving the problem

=== Expected result

As I understand it, this patch identifies a HEIC file from its own header even when File.type is
empty, so the upload goes into the conversion path instead of stalling. That is what I was checking
for. The symptom I reported in #81043 was the spinner never stopping.

That is what happened:

• The HEIC was converted to JPEG.
• A full set of sub-sizes was generated (150x150, 225x300, 768x1024, 1152x1536, 1536x2048, and -scaled).
• The original .heic was kept alongside them, at 1,286 KB. That matches the 1,316,390 bytes logged
  for the file on upload, and it still carries its original capture date, so the untouched original is
  being stored as described.
• No console errors.
• No warnings in debug.log. The image.php width/height warnings I reported earlier do not come back.

=== Additional Notes

1. The empty File.type here is not explained by a missing codec extension.

The description says an empty File.type is "what Windows without the HEVC extension reports for a .heic file".
On this machine both HEIF Image Extensions and HEVC Video Extensions are installed, and File.type was still empty on the upload itself. So the empty type does not seem to come from a missing extension.

The outcome matched the instructions: with the codecs present, the file converted.
I have not worked out what decides the type Windows reports here, so I am only reporting the observation rather than explaining it.

2. The 15 second timeout did not come into play here.

The browser reported that it cannot decode HEIC through the ImageDecoder API, so that step was skipped
and the timeout never applied. What fixed #81043 on my machine was the header check alone.

3. Timing.

It took somewhere between 30 seconds and a minute from the drop to the image appearing in the editor.
That covers the whole round trip, not the decode on its own - I did not measure the decode separately.
For scale, a ~1MB JPEG also takes about 10 seconds to upload on this setup, so a good part of that time is not decoding.

Mentioning it only in case the overall duration is useful alongside the timeout discussion.

=== Screenshots/Screencast with results

• After: the uploads folder, showing the converted IMG_1250.jpg with its sub-sizes and the original
  IMG_1250.heic kept beside them.

=== Support Content

The file used for this test is a photo straight off an iPhone, 1,316,390 bytes, with these brands in
its File Type Box:

ftyp heic / mif1 / MiPr / miaf / MiHB / heic

[t-hamano]

Thanks for the PR! Everything works pretty well im my environment. I left a few suggestions, but they are insignificant.

[t-hamano]

Suggested change

	- In HEIC-only upload mode, route files to the HEIC conversion by what they contain rather than by the MIME type the browser infers from their name, so a HEIC photo saved as `.jpg` or `.png` is no longer handed to a server-side path that cannot convert it either ([#81707](https://github.com/WordPress/gutenberg/issues/81707)).
	- In HEIC-only upload mode, route files to the HEIC conversion by what they contain rather than by the MIME type the browser infers from their name, so a HEIC photo saved as `.jpg` or `.png` is no longer handed to a server-side path that cannot convert it either ([#81737](https://github.com/WordPress/gutenberg/pull/81737)).

It would be better to link the changelog to the PR rather than the issue, as it makes it clearer what changes were actually made. Additionally, this entry needs to be moved to the Unreleased section.

[adamsilverstein]

Ah right, I see that in the guidelines now. Will update.

[adamsilverstein]

Done, with one small deviation from the suggestion.

Claude made the changelog edits, its summary:

Fixed in 5b1a83ccab7: both entries now link the PR and sit under Unreleased. The new isHeicFile export is a new public API, which the changelog guide files under New Features, so it got its own entry there and the Bug Fixes entry keeps the rest.

[t-hamano]

Suggested change

	// The major brand, then every compatible brand after the minor version.
	const brands = [ readBrand( 8 ) ];
	for ( let offset = 16; offset + 4 <= view.length; offset += 4 ) {
	brands.push( readBrand( offset ) );
	}
	// Anything past the box size belongs to the next box, not to the brands.
	const boxEnd = Math.min(
	view.length,
	new DataView( view.buffer, view.byteOffset ).getUint32( 0 )
	);
	// The major brand, then every compatible brand after the minor version.
	const brands = [ readBrand( 8 ) ];
	for ( let offset = 16; offset + 4 <= boxEnd; offset += 4 ) {
	brands.push( readBrand( offset ) );
	}

I'm not very familiar with this internal process, but Claude suggested this. Does this seem reasonable?

[adamsilverstein]

Yes, that's a real fix - the 64-byte read can run past a short box into the next one. Landed it with a test.

Claude checked the suggestion and wrote the test, its notes:

In 6143369a4f1, with a unit test that puts an avif word in the box after ftyp and checks the file still reads as HEIC; it fails on the old scan and passes now. A box size of 0 or 1 (the extended-size forms, which a File Type Box never uses) collapses the compatible-brand scan, but the major brand is still checked, so those degenerate cases stay safe.

[aduth]

Hey 👋 I wanted to give you a heads-up since this pull request is affected by recent validation changes for changelog files.

#83043 adds additional validation for changelog files. You'll note that this pull request is currently failing a "Required changes from trunk" check.

What you'll need to do: You will need to either rebase or merge the latest code from trunk. In addition, a cursory review of open pull requests identified this pull request as potentially failing under the new validation checks. You will want to double-check that any changes to CHANGELOG.md files follow the Maintaining Changelogs guidance, which has been improved as part of these recent changes.

[t-hamano]

LGTM!