Media: Remove the redundant __heicUploadSupport flag

[adamsilverstein]

What?

Removes the window.__heicUploadSupport flag and gates the HEIC canvas fallback on window.__clientSideMediaProcessing instead.

Fixes #80451

Why?

The two flags are emitted under identical conditions - both are gated by the same wp_client_side_media_processing_enabled filter (all of lib/media/load.php, including gutenberg_set_heic_upload_support_flag(), early-returns when the filter is off), so __heicUploadSupport carries no information that __clientSideMediaProcessing doesn't. The browser-capability distinction (Safari canvas fallback vs. full vips pipeline) is already made client-side in shouldEnableHeicCanvasProcessing().

This also fixes Trac #65648 (Safari gets no client-side HEIC conversion on core-only WordPress 7.1 installs) without any core PHP change: core already emits __clientSideMediaProcessing for all browsers when the filter allows, so once this lands in the 7.1 package sync the canvas fallback activates in Safari on core. The alternative core-side fix (wordpress-develop#12561) would have added a second flag under conditions identical to the existing one, as noted in review feedback; that PR can be closed in favor of this one.

How?

• shouldEnableHeicCanvasProcessing() in @wordpress/block-editor now checks window.__clientSideMediaProcessing.
• The isSideloading check in the image block simplifies to a single flag check.
• The __heicUploadSupport window type declaration is removed from @wordpress/media-utils.
• gutenberg_set_heic_upload_support_flag() is removed; gutenberg_set_client_side_media_processing_flag() moves into the tier 1 section of lib/media/load.php since the flag now gates both processing modes.

E2E test fix

The HEIC snackbar spec previously activated the disable-client-side-media-processing test plugin, on the assumption that __heicUploadSupport stayed set while the full pipeline was disabled. In practice that plugin loads before Gutenberg (active_plugins is sorted, and gutenberg-test-plugins/… sorts before gutenberg/…), so the filter is already registered when lib/media/load.php runs its file-level check - neither flag was emitted, and the spec passed vacuously through the traditional server-side upload path (the fake HEIC's JPEG bytes get content-sniffed by wp_check_filetype_and_ext() and renamed to .jpg server-side, satisfying the assertions).

The spec now activates a new disable-cross-origin-isolation test plugin, which filters gutenberg_use_document_isolation_policy off while leaving client-side media processing enabled. Without cross-origin isolation, SharedArrayBuffer is unavailable, the vips pipeline fails feature detection, and the editor genuinely takes the HEIC canvas path in Chromium - restoring the regression coverage for #80369.

Behavior change

Plugin sites that disable the wp_client_side_media_processing_enabled filter in a plugin loading after Gutenberg now also disable Safari HEIC canvas conversion (previously the HEIC flag skipped the late re-check). This matches the filter's intended semantics - one filter controls all client-side processing - and is already the behavior on Chromium.

Testing Instructions

1. In Safari (or any Chromium browser with the disable-cross-origin-isolation test plugin active), on a server without HEIC support, upload a HEIC image to a post.
2. Verify the image is converted to JPEG client-side and sub-sizes/srcset work on the front end in all browsers.
3. Filter wp_client_side_media_processing_enabled to false and verify HEIC uploads fall back to the server-side path.

npm run test:e2e -- test/e2e/specs/editor/various/heic-upload-progress-snackbar.spec.js

[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: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: swissspidy <swissspidy@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]

Size Change: -21 B (0%)

Total Size: 7.74 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	426 kB	-7 B (0%)
build/scripts/block-library/index.min.js	354 kB	-14 B (0%)

_{compressed-size-action}

[ramonjd]

I just noticed this PR:

• Media: Set window.__heicUploadSupport flag so Safari gets client-side HEIC conversion #65648  #80453

Does this one make that one redundant?

[adamsilverstein]

I just noticed this PR:

• Media: Set window.__heicUploadSupport flag so Safari gets client-side HEIC conversion #65648  #80453

Does this one make that one redundant?

Yes it looks like it, I'll review to see if there is anything useful to add here.

[adamsilverstein]

I reviewed #80453 - it turns out to be a near-identical subset of the changes here (despite its description, its diff also removes the __heicUploadSupport flag rather than setting it), so there is nothing to pull in. It is missing the action-time re-check of the disable filter, the changelog entries, and the e2e sideload assertion that proves the canvas path ran. I left a note over there suggesting it be closed in favor of this PR.

[andrewserong]

Thanks for following up with this one, it's testing (and looking) good to me!

[github-actions]

Flaky tests detected in 5aa2bc9.
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/29763299778
📝 Reported issues:

• [Flaky Test] Should insert content using the global inserter #78924 in /test/e2e/specs/widgets/editing-widgets.spec.js
• [Flaky Test] persists table layout across all tabs with unified view persistence #80156 in /test/e2e/specs/site-editor/pages-view-persistence.spec.js

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick ae9a73420ee8a476b32885d6938082a24e754e65

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[adamsilverstein]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

I'll cherry pick a backport.

[adamsilverstein]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

I'll cherry pick a backport.

@t-hamano - ready in #80486

[t-hamano]

This PR was backported by #80486. I also intend to backport this to Gutenberg 23.6 RC, but since cherry-picking #80486 is less likely to cause conflicts, I will add the Backport to Gutenberg RC label to #80486.