Media: Stop injecting crossorigin attributes under Document-Isolation-Policy

[adamsilverstein]

What?

Fixes #82691

Sends the Document-Isolation-Policy header directly and stops adding crossorigin="anonymous" to cross-origin resources, on both the PHP side and the JavaScript side.

Core backport: WordPress/wordpress-develop#13446. Trac: https://core.trac.wordpress.org/ticket/65930. Safari keeps its injection through the Client-Side Media Everywhere plugin: adamsilverstein/client-side-media-everywhere#63.

Why?

I spent some time testing what isolate-and-credentialless actually blocks, and the answer is nothing that the crossorigin injection was helping with.

Claude ran the browser tests and wrote up the reasoning:

isolate-and-credentialless loads cross-origin subresources without credentials instead of blocking them. So a cross-origin script, stylesheet, image, audio or video element works with no crossorigin attribute at all. Adding crossorigin="anonymous" turns the load into a CORS request, which fails for any host that does not send Access-Control-Allow-Origin, such as media offloaded to a CDN. That is the bug behind #76476 and #80535, and AUDIO, VIDEO, SOURCE, SCRIPT and LINK still had it.

Verified with a two-origin harness (localhost:4801 document, 127.0.0.1:4802 resources) in Chromium 151 and Chrome 152, with crossOriginIsolated === true on the DIP pages:

Resource, host without CORS headers	No DIP	DIP
img, script, stylesheet, audio, video, <source>, no attribute	loads	loads
same, with crossorigin="anonymous"	fails, media error code 4	fails, media error code 4
img with the attribute, host sends CORS	loads, canvas readback works	loads, canvas readback works

DIP changes nothing in any row. The attribute only buys canvas pixel readback, and only when the host serves CORS. Nothing in Gutenberg reads pixels out of remote media: @wordpress/upload-media has no crossOrigin usage and works on local blobs. The two places that do need readback (the Cover block's dominant color and the image editor) already set crossOrigin on the element they create, through the media.crossOrigin filter.

The injection dates from the require-corp era of the experiment (#64650), where it was the only way for anything cross-origin to load. It came along unchanged in the switch to DIP (#75991). #76618 carved out IMG after CDN images broke, and the question raised there of whether the rest should go too never got answered.

Removing the PHP output buffer also retires the class of failure in Trac #65930: running WP_HTML_Tag_Processor over the finished document inside an ob_start() display handler.

How?

• gutenberg_send_document_isolation_policy_header() replaces gutenberg_start_cross_origin_isolation_output_buffer() and gutenberg_add_crossorigin_attributes(). The gutenberg_use_document_isolation_policy filter is unchanged.
• The packages/block-editor/src/hooks/cross-origin-isolation.js MutationObserver and its test are removed.
• gutenberg_override_media_templates() now strips the attribute that WordPress 7.1 forces onto AUDIO and VIDEO in the media templates, and only activates on 7.1 (the one release whose core does that), so media library previews of CDN audio and video work for plugin users until the core fix ships.
• Docs updated to describe why no attribute is needed.

Testing Instructions

Chrome 137 or newer for everything except the last group. The Playground link at the top works, or a local wp-env with this branch built.

Confirm client-side media processing is active first:

1. Open a post in the editor. In the Network panel, the post.php document response carries Document-Isolation-Policy: isolate-and-credentialless and no Cross-Origin-Embedder-Policy header.
2. In the console, window.crossOriginIsolated is true, typeof SharedArrayBuffer is "function", and window.__clientSideMediaProcessing is true.
3. document.querySelectorAll( '[crossorigin]' ).length is 0. On trunk, every cross-origin script and stylesheet on the page carries the attribute.
4. If step 1 or 2 fails: check that no other plugin returns false from the wp_client_side_media_processing_enabled or gutenberg_use_document_isolation_policy filters, that the user has upload_files, and that the URL has no action parameter other than edit. The header is only sent on the post editor, site editor and widgets screens.

Uploads across formats (all in test/e2e/assets/):

5. Drag each of these onto the canvas, one at a time: 1024x768_e2e_test_image.png, 1024x768_e2e_test_image_size.jpeg, 200x150_e2e_test_image_decode.webp, 200x150_e2e_test_image_decode.avif, 1024x768_e2e_test_image_rotated_exif.avif and 599x441_e2e_test_image_animated.gif. For each, the Network panel shows the vips .wasm fetch (first upload only), POST /wp/v2/media for the file, then sideload requests for the sub-sizes. The Image block renders and the attachment in Media > Library lists its sizes. The rotated AVIF displays upright.
6. On a Mac, drag in a HEIC photo. It uploads through the native decode path, lands as a JPEG with the HEIC companion, and the Image block renders.

Things the old injection broke, or that DIP could break:

7. Cross-origin media from a host without CORS headers. Quickest recipe in wp-env is an mu-plugin that moves attachment URLs to a second origin on the same server (adjust the port to yours):

   add_filter( 'wp_get_attachment_url', fn( $url ) => str_replace( 'localhost:8888', '127.0.0.1:8888', $url ) );

   Then: Image, Gallery, Cover, Video, Audio and File blocks with media library items all render and play in the editor. Open the Media Library modal from an Image block, select a video and an audio attachment, and confirm the attachment details preview plays (that is the 7.1 template override). The Media > Library grid shows thumbnails. On trunk the video and audio previews fail with media error code 4.
8. Image block, "Insert from URL", https://placehold.jp/1024x768.jpg (no CORS headers). The canvas and sidebar previews render.
9. Classic block: insert it, TinyMCE loads with its toolbar, type some text, use its Add Media button to insert a media library image, switch between the Visual and Code tabs, then Convert to blocks. No console errors. TinyMCE and its skin CSS are the largest cross-origin script and stylesheet loads on a site that offloads wp-includes to a CDN, so if you have that setup this is the block to test there.
10. Embed blocks: YouTube, Vimeo, X and a WordPress post embed. The previews render in their sandboxed iframes.
11. Openverse: inserter, Media tab, Openverse, browse. Thumbnails render, and inserting one imports it through the server-side sideload and renders in an Image block.
12. Avatars: the Avatar and Post Author blocks render the Gravatar image, and the Comments block renders commenter avatars.
13. Cover block with a media library image: the overlay picks up the dominant color. That path sets crossOrigin itself through the media.crossOrigin filter, so with the recipe from step 7 it should fall back to the default overlay - worth confirming no console error is left behind.
14. Image editing: crop and rotate a media library image from the Image block toolbar and apply. The preview and the saved edit both work.
15. Font Library: Appearance > Editor > Styles > Typography > Manage fonts > Install Fonts, pick a Google font. Previews render from fonts.gstatic.com and the install succeeds.
16. Third-party scripts and styles: an mu-plugin that enqueues a stylesheet and a script from other origins on enqueue_block_editor_assets (eg. a Google Fonts CSS URL and any cdnjs script). Both load and run with no crossorigin attribute added. These are exactly the tags the old output buffer rewrote.
17. Site editor and Widgets screens: open Appearance > Editor, and Appearance > Widgets on a classic theme. Both load with crossOriginIsolated === true, and an upload there also goes through sideload.
18. Preview in new tab and the View post link from the post-publish panel open the front end normally.

Browsers without DIP support:

19. Firefox and Safari: the editor loads, crossOriginIsolated is false, uploads fall back to server-side processing (no sideload requests, sub-sizes come back in the media response as usual), and the media and embed steps above still render. Safari on macOS still uploads HEIC through the native decode path.

Automated:

20. npm run test:unit:php:base -- --filter media_processing passes. packages/block-editor/src/hooks/cross-origin-isolation.js and its test are gone, so npm run test:unit -- cross-origin-isolation finds nothing to run.

AI Use

Code and description both written with 🤖 Claude Code. 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: swissspidy <swissspidy@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]

🤖 PR meta 🤖

📦 Bundle size

Size Change: -302 B (0%)

Total Size: 8.06 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	473 kB	-302 B (-0.06%)

_{8ef15ea Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	cf43587	trunk	% Change
timeToFirstByte	55.95 ms +14.39% -2.95%	60.3 ms +8.29% -3.32%	-7.21%
largestContentfulPaint	96 ms +12.5% -6.25%	98 ms +6.12% -6.12%	-2.04%
lcpMinusTtfb	36.7 ms +17.71% -5.45%	35.5 ms +2.39% -4.65%	3.38%
wpBeforeTemplate	27.92 ms +12.82% -2.18%	29.44 ms +19.12% -3.74%	-5.16%
wpTemplate	24.06 ms +7.69% -4.32%	25.12 ms +6.57% -4.62%	-4.22%
wpTotal	51.99 ms +13.77% -3.31%	56.17 ms +6.8% -3.36%	-7.44%
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	cf43587	trunk	% Change
timeToFirstByte	43.7 ms +15.79% -5.72%	44.55 ms +5.27% -3.7%	-1.91%
largestContentfulPaint	100 ms +16% -4%	100 ms +4% -0%	0%
lcpMinusTtfb	54.9 ms +16.85% -0.64%	56 ms +1.96% -3.84%	-1.96%
wpBeforeTemplate	25.71 ms +18.59% -7.04%	24.73 ms +3.23% -0.32%	3.96%
wpTemplate	14.72 ms +6.59% -3.4%	15.3 ms +9.8% -3.14%	-3.79%
wpTotal	40.45 ms +14.73% -5.81%	41.16 ms +5.61% -4.01%	-1.72%
wpMemoryUsage	5.52 MB +0% -0%	5.48 MB +0% -0%	0.64%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	cf43587	trunk	% Change
mediaProcessingJpeg	410.32 ms +1.93% -0.92%	416.06 ms +0.86% -0.62%	-1.38%
mediaProcessingAvif	6177.21 ms +0.08% -0.08%	6182.81 ms +0.21% -0.25%	-0.09%
mediaProcessingJpegToAvif	4315.63 ms +0.5% -0.08%	4319.17 ms +0.34% -0.14%	-0.08%

media-upload

Metric	cf43587	trunk	% Change
jpegUploadProcessing	1466.85 ms +35.12% -1.76%	1435.1 ms +1.09% -0.91%	2.21%
pngUploadProcessing	232.53 ms +2.36% -5.44%	219.96 ms +5.06% -3.09%	5.71%
largeJpegUploadProcessing	1420.64 ms +1.58% -0.69%	1435.89 ms +0.67% -1.02%	-1.06%
multipleImageUploadProcessing	1647.62 ms +24.39% -3.28%	1615.78 ms +33.37% -1.24%	1.97%

post-editor

Metric	cf43587	trunk	% Change
serverResponse	429.24 ms +2.47% -5.02%	431.07 ms +5.89% -3.25%	-0.42%
firstPaint	255.08 ms +22.04% -26.56%	222.43 ms +30.99% -8.77%	14.68%
domContentLoaded	1058.96 ms +2.01% -2.05%	1308.59 ms +1.14% -0.59%	-19.08%
loaded	1060.14 ms +2.03% -2.05%	1309.82 ms +1.14% -0.59%	-19.06%
firstContentfulPaint	433.8 ms +2.99% -3.69%	439.24 ms +2.7% -1.57%	-1.24%
firstBlock	3144.45 ms +1.32% -0.55%	3517.67 ms +0.81% -1.33%	-10.61%
type	15.89 ms +5.48% -6.67%	16.13 ms +7.63% -3.78%	-1.49%
typeWithoutInspector	15.54 ms +8.17% -5.86%	16.2 ms +9.44% -8.64%	-4.07%
typeWithTopToolbar	18.29 ms +10.01% -4.81%	19.4 ms +5.52% -9.43%	-5.72%
typeContainer	9.5 ms +14.74% -3.16%	9.24 ms +3.9% -7.58%	2.81%
focus	86.66 ms +2.35% -8.26%	87.32 ms +9.94% -9.07%	-0.76%
firstFocus	208.02 ms +0% -0%	187.41 ms +0% -0%	11%
selectAll	503.4 ms +3.95% -0.77%	530.54 ms +2.3% -4.01%	-5.12%
listViewOpen	70.93 ms +7.6% -7.22%	72.46 ms +8.54% -9.99%	-2.11%
inserterOpen	25.97 ms +16.75% -5.62%	24.48 ms +16.38% -5.35%	6.09%
inserterHover	3.85 ms +5.45% -4.16%	5.24 ms +15.08% -10.31%	-26.53%
inserterSearch	8.84 ms +8.82% -10.97%	9.99 ms +5.91% -9.71%	-11.51%
loadPatterns	692.18 ms +3.47% -1.85%	667.51 ms +5.47% -2.24%	3.7%
wpTotal	419.57 ms +2.24% -5.14%	421.55 ms +5.97% -3.38%	-0.47%
wpMemoryUsage	13.06 MB +0% -0%	13.03 MB +0% -0%	0.28%
wpDbQueries	54 +0% -0%	54 +0% -1.85%	0%

site-editor

Metric	cf43587	trunk	% Change
serverResponse	407.79 ms +1.89% -8.17%	400.19 ms +2.77% -3.35%	1.9%
firstPaint	237.12 ms +27.05% -16.34%	226.11 ms +8.68% -21.22%	4.87%
domContentLoaded	1014.98 ms +1.64% -0.78%	1251.53 ms +0.99% -1.08%	-18.9%
loaded	1016.02 ms +1.64% -0.78%	1252.64 ms +0.98% -1.09%	-18.89%
firstContentfulPaint	397.67 ms +3.67% -2.96%	396.05 ms +2.05% -0.92%	0.41%
firstBlock	3735.67 ms +0.24% -0.62%	4008.45 ms +0.96% -0.62%	-6.81%
type	13.82 ms +6.8% -8.9%	13.18 ms +13.51% -3.57%	4.86%
navigate	95.82 ms +12.79% -1.93%	98.55 ms +15.69% -2.45%	-2.77%
loadPatterns	1280.26 ms +10.17% -5.76%	1290.66 ms +9.38% -5.43%	-0.81%
loadPages	1103.11 ms +2.91% -3.07%	1089.8 ms +3.27% -3.72%	1.22%
wpTotal	398.79 ms +1.92% -8.34%	391.21 ms +2.89% -3.44%	1.94%
wpMemoryUsage	12.02 MB +0% -0%	12.04 MB +0% -0%	-0.14%
wpDbQueries	43.5 +1.15% -1.15%	43.5 +1.15% -1.15%	0%

_{8ef15ea 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.

As a user I want to be able to customize the navigation overlay with styled content (Site Editor v2) in /test/e2e/specs/site-editor/navigation-overlay-template-part.spec.js, passed after 2 failed attempts.

Error: apiRequestContext.fetch: socket hang up
Call log:
  - → GET http://localhost:8889/wp-json/wp/v2/templates
    - user-agent: Playwright/1.63.0 (x64; ubuntu 24.04) node/24.18 CI/1
    - accept: */*
    - accept-encoding: gzip,deflate,br
    - X-WP-Nonce: 80478de167
    - cookie: wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_23778236db82f19306f247e20a353a99=admin%7C1789254053%7CwO8rHsRqd7UZMGXIhbOyVOaaGpWZJ8j2z0OcMfdvxdh%7Cf4e41b1393b2352db7d3990d710703792d02951378df15dd0c44287e872db389; wp-settings-time-1=1789081390

    at RequestUtils.rest (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/rest.ts:112:39)
    at RequestUtils.deleteAllTemplates (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/templates.ts:35:31)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/site-editor/navigation-overlay-template-part.spec.js:57:22
TimeoutError: locator.click: Timeout 10000ms exceeded.
Call log:
  - waiting for getByRole('button', { name: 'Create overlay', exact: true })

    at createNavigationOverlay (/home/runner/work/gutenberg/gutenberg/test/e2e/specs/site-editor/navigation-overlay-template-part.spec.js:44:28)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/site-editor/navigation-overlay-template-part.spec.js:114:4

_{8ef15ea Run}

[adamsilverstein]

I had Claude run thru the testing instructions in the PR description and everything works as expected. I will also do some manual testing.

Here is the report from Claude:

Details

> Environment: wp-env on WordPress 7.2-alpha-63537 with this branch built and active, driven through Playwright in Chromium 151, Chrome 152, Firefox 153 and WebKit 26.5. Core has not landed https://github.com/WordPress/wordpress-develop/pull/13446 yet, so `wp_add_crossorigin_attributes()` still exists and the 7.1 media template override path is live here. > > Steps 1-4, the header and the attribute count. The `post.php` document carries `Document-Isolation-Policy: isolate-and-credentialless` and no `Cross-Origin-Embedder-Policy`. `crossOriginIsolated` is `true`, `SharedArrayBuffer` is a function, `__clientSideMediaProcessing` is `true`, and `document.querySelectorAll('[crossorigin]').length` is `0`. A stock wp-env has nothing cross-origin on the page, so step 3 was re-run together with step 16: an mu-plugin enqueueing a `fonts.googleapis.com` stylesheet and a `cdnjs.cloudflare.com` script on `enqueue_block_editor_assets`. Both load and the script runs, and the attribute count stays at `0`. Those are exactly the tags the old output buffer rewrote. > > Step 5, uploads. All six fixtures upload through the client-side path - `POST /wp/v2/media`, then `sideload` per sub-size, then `finalize` - and render in the Image block with no `crossorigin` attribute. `1024x768_e2e_test_image_rotated_exif.avif` displays upright. Sub-sizes land in `wp_get_attachment_metadata()` for the ones that were left to finish; the rotated AVIF was cut off mid-sideload by the test harness rather than by anything on the page. > > Step 6, HEIC. In headless Chromium the decode fails and the narrowed message from #82265 appears ("Chrome couldn't decode HEIC on this Mac..."), which is a headless limitation rather than anything this PR touches. Re-run in real Chrome on macOS it works: `hill-800x600.heic` uploads through the native decode path, lands as `hill-800x600-1.jpg` with sub-sizes, and `hill-800x600-1.heic` is written alongside it. > > Step 7, cross-origin media with no CORS headers. Using the mu-plugin recipe to move attachment URLs to `127.0.0.1:9041` (verified to send no `Access-Control-Allow-Origin`): Image, Gallery, Cover, Video, Audio and File blocks all render, video and audio both reach `readyState 4` with `error === null`, and the attribute count in the canvas is `0`. In Media > Library the grid thumbnails load and the attachment details video preview plays. The audio preview sits at `readyState 0` with no error, which is just the template's `preload="none"`. Scanning the admin-footer templates for `crossorigin` returns nothing on both `post-new.php` and `upload.php`, so `gutenberg_override_media_templates()` is stripping what 7.1 core forces in. > > The negative control is the clearest single result. On the same DIP-isolated page, against that same no-CORS host: > > | element | attribute | result | > | --- | --- | --- | > | video | none | `readyState 4`, no error | > | video | `crossorigin="anonymous"` | `readyState 0`, media error code 4 | > | audio | none | `readyState 4`, 122s duration read | > | audio | `crossorigin="anonymous"` | `readyState 0`, media error code 4 | > > Step 8, Insert from URL with `https://placehold.jp/1024x768.jpg` renders in the canvas. > > Step 9, Classic block. TinyMCE loads with 37 toolbar buttons and its `skins/lightgray/skin.min.css`, typing works, and Convert to blocks produces a paragraph with the text intact. No console errors. Worth noting the Classic block now opens a "Classic Editor" modal that has no Add Media button and no Visual/Code tabs, so those parts of step 9 no longer apply to the current UI. > > Step 10, embeds. YouTube, Vimeo and a wordpress.org post embed all render their previews in the sandboxed iframes. X does not resolve, but that is upstream - `publish.twitter.com/oembed` 301s for that URL from this network, so the WordPress proxy returns 404. Unrelated to this change. > > Step 11, Openverse. Thumbnails render in the inserter, and inserting one imports it and renders it in an Image block. > > Step 12, avatars. Avatar and Post Author both load their `secure.gravatar.com` image with no attribute, and the Comments block renders commenter avatars the same way. > > Step 13, Cover dominant color. With the step 7 recipe active the Cover block image renders and the overlay falls back to the default dark treatment, with no console error left behind. That matches what the instructions predicted. > > Step 14, image editing. Rotate 90° clockwise then Save posts `POST /wp/v2/media/39/edit`, returns 201, and the block updates to the `-edited.jpg` source. No console errors. > > Step 15, Font Library. The Google Fonts collection renders each font name in its own typeface, so the `fonts.gstatic.com` preview faces are loading. Installing ABeeZee succeeded and created the `wp_font_family` post plus two `wp_font_face` posts locally. > > Step 17, other screens. `site-editor.php` and `widgets.php` both send the header and report `crossOriginIsolated === true` with zero attributes, and an upload on each goes through `sideload`. The widgets screen needed a classic theme switch to Twenty Twenty-One to be reachable. > > Step 18, front end. The home page, a draft preview and a published post all come back with no `Document-Isolation-Policy` header, `crossOriginIsolated === false`, and the cross-origin media in the post renders and loads. > > Step 19, browsers without DIP. Firefox and WebKit both behave the same: `crossOriginIsolated` is `false`, `SharedArrayBuffer` is undefined, uploads fall back to the server (`POST /wp/v2/media` and nothing else, no `sideload`), and the cross-origin images, video and audio all render with `readyState 4`. Note this was headless WebKit rather than Safari proper, so the Safari HEIC path is still worth a manual pass. > > Step 20, automated. `npm run test:unit:php:base -- --filter media_processing` is `OK (13 tests, 47 assertions)`. `npm run test:unit -- cross-origin-isolation` reports `Pattern: cross-origin-isolation - 0 matches`, since the hook and its test are gone. > > Two things not covered: Safari itself, and a side-by-side run on trunk to confirm the before state. The negative control above demonstrates the mechanism directly on this branch instead.

Here are the screenshots that Claude captured:

Details

[swissspidy]

Just to confirm, the attributes are only needed when using Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy headers, but not when using Document-Isolation-Policy? In that case this sounds good to me.

DIP changes nothing in any row. The attribute only buys canvas pixel readback, and only when the host serves CORS. Nothing in Gutenberg reads pixels out of remote media: @wordpress/upload-media has no crossOrigin usage and works on local blobs. The two places that do need readback (the Cover block's dominant color and the image editor) already set crossOrigin on the element they create, through the media.crossOrigin filter.

Makes sense.

[adamsilverstein]

Just to confirm, the attributes are only needed when using Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy headers, but not when using Document-Isolation-Policy? In that case this sounds good to me.

Right, this support was a remnant of our previous effort to support Safari which we dropped in the end because the experience was't always great (some things could break). I asked Claude Fable to confirm and it added this nuance:

the attribute is only relevant under a require-corp policy (COEP or DIP), and not under credentialless (COEP or DIP)

So I expect this change will fix #82691 and other potential conflicts. I'll make sure my plugin to support Safari/Firefox (https://wordpress.org/plugins/client-side-media-everywhere/) gets updated with the removed code (see adamsilverstein/client-side-media-everywhere#63)

[adamsilverstein]

Marking this as needing to backported to the next minor release in core (7.1.2).

[andrewserong]

Sorry, didn't get a chance to review before merge, but just a post-merged comment to say it was testing well! This restores the embeds nicely (e.g. PDF uploads, too), while preserving client-side media processing:

Glad it'll be picked up for 7.1.2 🎉