Enabling Client Side Media Processing in Gutenberg blows Playground

[SirLouen]

Reproduction Steps:

1. Enable the Gutenberg plugin
   https://playground.wordpress.net/?gutenberg-branch=trunk
2. Go to Gutenberg > Experiments
3. Enable Client-side media processing
4. Add a New Post
5. 💥

[bph]

I can confirm. From the browser console screenshot, it might be a CORS issue or so.

The Logs Tab doesn't reveal anything relevant. This is the only entry

[02-Dec-2025 08:17:07 UTC] JavaScript warn: The "zipPath" option of the unzip() Blueprint step is deprecated and will be removed. Use "zipFile" instead.

That's there too few, the browser console has too many entries.

This is the screen I see:

[adamziel]

Client-side media processing uses SharedArrayBuffer which, in turn, requires cross-origin isolation via the Cross-Origin-Embedder-Policy (COEP) and Cross-Origin-Resource-Policy (CORP) headers. Those headers are viral-ish, and once a part of a site sets them, the rest of the site must follow. This is why YouTube embeds broke at one point when I was experimenting with these.

I can see the following options:

• Set the COEP/CORP headers only on the editor screens and only when media experiments are enabled – this will break embeds YouTube embeds, but only in the editor. That's consistent with what's likely happening in "native" WordPress and seems like a good option.
• Set the COEP/CORP headers for the entire Playground – that's easier technically, but it will also break embeds such as YouTube site-wide so it's not a good option.
• Don't support client-side media processing. That's not a good option, I'm only mentioning it for completeness.

I wonder if there are other good options I'm missing here – cc @swissspidy @ramonjd @brandonpayton

[swissspidy]

Set the COEP/CORP headers only on the editor screens and only when media experiments are enabled

This should already be the case in the current implementation in Gutenberg and in the Media Experiments plugin

[adamziel]

@swissspidy Oh, that's right!:

add_action( 'load-post.php', 'gutenberg_set_up_cross_origin_isolation' );
add_action( 'load-post-new.php', 'gutenberg_set_up_cross_origin_isolation' );
add_action( 'load-site-editor.php', 'gutenberg_set_up_cross_origin_isolation' );
add_action( 'load-widgets.php', 'gutenberg_set_up_cross_origin_isolation' );

I somehow assumed the entire server configuration needs updating to serve all the CSS, JS, etc. assets with COEP/CORP headers, but it seems like doing it just for the editor page is enough?

🤔

The difficult part seems to be embedding WordPress in an iframe. I think Playground is blowing up because we are embedding an origin-isolated resource in a non-origin-isolated page. If that's correct, we'd need to serve these headers on the entire https://playground.wordpress.net/ – but that would affect the editor even when the media experiment is not enabled.

Ideally, we'd be able to activate the origin-isolated mode when the editor demands it, and deactivate it once we navigate away from the isolated editor. However, I don't think we can switch between those modes without a full playground.wordpress.net reload. This means we need to either:

• Stick to a non-isolated mode – and don't support client-side media processing
• Stick to an isolated mode – and don't support embeds
• Dynamically switch between the two modes – and make the user experience more rough, e.g. we may surprise the user with a sudden page reload, we'll likely lose some UI state, and we may also trigger the "are you sure you want to reload?" alert at times. We'll also need to save the temporary Playground in OPFS and restore it from there, which could take a few seconds and add to the roughness.

I wonder if I'm missing a fourth solution here that would solve it without any big downsides. Maybe an explicit ?origin-isolation setting that must be present from the beginning of the Playground session?

[swissspidy]

You might want to check out Document Isolation Policy, which is supposed to supersede COEP/COOP and applies per frame. Chrome only now though at the moment. See https://developer.chrome.com/blog/document-isolation-policy

[JanJakes]

I asked Claude to investigate, summarize, and research the possible solutions for me, and it did an impressive job (see below).

Then I went on to try Document Isolation Policy, and it appears to be working: #3020

[Claude summary of the issue below]

---

Root Cause

When the "Client-side media processing" experiment is enabled in Gutenberg within WordPress Playground, the application crashes because:

1. Gutenberg's media processing uses wasm-vips (image processing) and ffmpeg.wasm (video/audio processing)
2. These WebAssembly libraries require SharedArrayBuffer for multi-threaded operations
3. SharedArrayBuffer requires cross-origin isolation via COEP (Cross-Origin-Embedder-Policy) and CORP (Cross-Origin-Resource-Policy) headers
4. Playground deliberately avoids these headers because they break iframe embedding and third-party embeds (YouTube, etc.)

Assumptions Verified

1. Playground explicitly avoids COEP/CORP headers

   Found in packages/php-wasm/universal/src/lib/comlink-sync.ts:22-26:

   * SharedArrayBuffer is an option, but it requires more restrictive CORP+COEP
   * headers which breaks, e.g., YouTube embeds.

2. Service worker manipulates response headers but doesn't add cross-origin isolation

   In packages/php-wasm/web-service-worker/src/utils.ts, the service worker:

   • Removes x-frame-options to allow iframe embedding
   • Removes frame-ancestors from CSP to allow cross-origin embedding
   • Does NOT add COEP/COOP headers

3. The iframe architecture is complex

   Playground uses nested iframes, and the Gutenberg site editor adds another level that Playground patches in service-worker.ts.

4. Gutenberg does add headers when experiment is enabled (as @swissspidy mentioned)

   The problem is that these headers conflict with Playground's iframe embedding model.

Solution Evaluation

Option	Complexity	Viability	Notes
Set headers only on editor screens	Very High	Low	Would require detecting when Gutenberg experiment is enabled. Embeds in editor would still break. Site editor iframe patching could break.
Set headers site-wide	Low	Very Low	Breaks ALL embeds everywhere (YouTube, Vimeo, Twitter, etc.). Not viable for a WordPress testing environment.
Don't support (document limitation)	None	High	Simple, honest approach. Document that this experiment is incompatible with Playground's architecture.
Document Isolation Policy	Medium	Medium	New Chrome feature (Chrome 137+) enables per-frame isolation without affecting child frames. Chrome desktop only.
Hybrid approach	Medium	Best	Use Document Isolation Policy when available, graceful degradation with informative message when not.

Document Isolation Policy - A Potential Path Forward

Document Isolation Policy is a new feature shipping in Chrome 137 (late 2025) that differs from COEP:

• Applies per-frame, not site-wide
• Doesn't require embedded iframes to support COEP
• Documents can still open cross-origin popups and embed iframes normally
• Header: Document-Isolation-Policy: isolate-and-credentialless

Limitations:

• Chrome 137+ desktop only (no Firefox, Safari, or mobile)
• Isolated frames lose synchronous DOM access to same-origin non-isolated frames

Recommendation

Hybrid approach with clear documentation:

1. Detect Document Isolation Policy support via feature detection
2. When supported (Chrome 137+): Add Document-Isolation-Policy: isolate-and-credentialless header
3. When not supported: Display a clear message explaining the limitation when the Gutenberg experiment is detected
4. Document the limitation in Playground docs with browser compatibility info

Alternatively, wait for broader browser support - Document Isolation Policy is very new. We could document the current limitation and implement when Firefox/Safari add support.

References

• Document Isolation Policy - Chrome Blog
• Document Isolation Policy Explainer
• Client-side media processing in WordPress - Pascal Birchler
• Gutenberg Tracking Issue #61447
• Making your website cross-origin isolated - web.dev

[adamziel]

@JanJakes Oh! So it seems like using that header in Chrome 137+ would already improve the situation for some users? And perhaps we can even do it at a service worker level to swap the CORP/COEP headers for that one when we detect Chrome? Let's try that, it seems like a worthwhile plan.

[adamziel]

#3028 might fix it in Chrome