Skip to content

Broaden DIP header scope to all admin pages - #76662

Draft
adamsilverstein wants to merge 8 commits into
trunkfrom
fix/broaden-dip-header-scope
Draft

Broaden DIP header scope to all admin pages#76662
adamsilverstein wants to merge 8 commits into
trunkfrom
fix/broaden-dip-header-scope

Conversation

@adamsilverstein

@adamsilverstein adamsilverstein commented Mar 19, 2026

Copy link
Copy Markdown
Member

Summary

Send the Document-Isolation-Policy (DIP) header on all admin pages rather than only on specific block-editor screens. This keeps navigations across admin screens (site editor, template editing, pattern editing, etc.) in the same agent cluster, preserving cross-window communication and SharedArrayBuffer access for WASM-based media processing on Chromium 137+.

  • Hook on admin_init instead of the narrow load-post.php / load-post-new.php / load-site-editor.php / load-widgets.php set.
  • Skip when the user lacks the upload_files capability.
  • Keep the existing skip for third-party page builders that override the block editor via a custom action query parameter.
  • Remove the now-unneeded gutenberg-test-plugin-disable-client-side-media-processing activations in E2E tests.

DIP remains an admin-only concern — the front-end preview is explicitly out of scope.

Testing instructions

  1. Run Chromium 137+ against a dev build of this PR.
  2. Open the Site Editor (Appearance → Editor) and upload an image into a template or template part — the upload should succeed and be processed client-side (check the Network tab for the wasm-vips worker).
  3. Open a pattern for editing from Appearance → Patterns (or via Create pattern from a block) and upload an image inside the pattern — it should also succeed.
  4. Open the classic post editor and upload an image — no regression.
  5. Verify the `Document-Isolation-Policy: isolate-and-require-corp` response header is present on `/wp-admin/index.php`, `/wp-admin/site-editor.php`, `/wp-admin/edit.php`, and `/wp-admin/post.php?post=…&action=edit` for a user with `upload_files`.
  6. Sign in as a Subscriber (no `upload_files`) and confirm the header is NOT sent on any admin page.
  7. Visit a third-party editor URL with `?action=elementor` (or similar) and confirm the header is NOT sent.
  8. Run `vendor/bin/phpunit phpunit/media/media-processing-test.php`.

Fixes #77633.

Send the Document-Isolation-Policy header on all admin pages
and front-end preview pages instead of only specific editor
screens. This keeps all admin navigations (site editor,
template operations, pattern editing) and preview popups in
the same agent cluster, preserving cross-window communication
in Chromium 137+.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Mar 19, 2026

Copy link
Copy Markdown

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>

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

…ounds

Now that the DIP header is sent on all admin pages and preview pages,
the agent cluster mismatch that previously broke cross-window
communication no longer occurs. These test workarounds are no longer
needed.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@adamsilverstein adamsilverstein added the [Type] Bug An existing feature does not function as intended label Mar 19, 2026
@github-actions

github-actions Bot commented Mar 19, 2026

Copy link
Copy Markdown

Size Change: -1.18 kB (-0.01%)

Total Size: 8.05 MB

📦 View Changed
Filename Size Change
build/scripts/edit-site/index.min.js 297 kB -29 B (-0.01%)
build/scripts/editor/index.min.js 472 kB -1.15 kB (-0.24%)

compressed-size-action

@github-actions

github-actions Bot commented Mar 19, 2026

Copy link
Copy Markdown

Flaky tests detected in 3dde058.
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/27820882807
📝 Reported issues:

@adamsilverstein
adamsilverstein marked this pull request as draft March 25, 2026 17:05
Resolve conflicts by keeping the broader DIP scope (admin_init +
template_redirect) from this branch while incorporating trunk's
third-party editor `action` query param skip. Drop the test plugin
workarounds that trunk re-added in reordered hook positions -- DIP is
now broad enough that the agent cluster mismatch no longer occurs.
DIP is an admin-context feature for WASM-based media processing; the
front-end preview doesn't need cross-origin isolation and shouldn't
send the header. Remove gutenberg_set_up_cross_origin_isolation_for_preview()
and its template_redirect action.
@adamsilverstein adamsilverstein changed the title Media: Broaden DIP header to all admin and preview pages Media: Broaden DIP header scope to all admin pages Apr 23, 2026
@adamsilverstein adamsilverstein self-assigned this Apr 23, 2026
@adamsilverstein
adamsilverstein requested review from andrewserong and youknowriad and removed request for ajitbohra, nerrad, ntwb and spacedmonkey April 28, 2026 17:41
@adamsilverstein adamsilverstein added the [Feature] Client Side Media Media processing in the browser with WASM label Apr 28, 2026
@andrewserong

Copy link
Copy Markdown
Contributor

Since this broadens the scope of the DIP header to all admin pages, would this be better to propose in trac/wordpress-develop and get some more folks to take a look? Code-wise it's a simple change, but I feel like I don't quite have the knowledge to evaluate how safe this might or might not be.

@adamsilverstein
adamsilverstein requested a review from adamziel May 7, 2026 14:09
@adamsilverstein

Copy link
Copy Markdown
Member Author

Since this broadens the scope of the DIP header to all admin pages, would this be better to propose in trac/wordpress-develop and get some more folks to take a look?

I'd love to hear from more reviewers if they anticipate problems with this. Maybe @adamziel can weigh in, I'm guessing in Playground the Document Isolation Policy already extends to the site editor and other areas?

The main advantage of broadening the scope is enabling client side media in these other contexts like the site editor. That said, I'm not sure media uploads are actually available? It also helps us avoid disabling the feature for some test runs.

@adamsilverstein

Copy link
Copy Markdown
Member Author

Since this broadens the scope of the DIP header to all admin pages, would this be better to propose in trac/wordpress-develop and get some more folks to take a look? Code-wise it's a simple change, but I feel like I don't quite have the knowledge to evaluate how safe this might or might not be.

I will work on a core backport for this then open a trac ticket for further core discussion.

adamsilverstein added a commit to adamsilverstein/wordpress-develop that referenced this pull request Jun 19, 2026
Send the Document-Isolation-Policy (DIP) header on every admin page via
`admin_init` rather than only on the four block-editor screens
(`load-post.php`, `load-post-new.php`, `load-site-editor.php`, and
`load-widgets.php`).

Hooking the narrow set of screens placed the editor in its own browser
agent cluster while sibling admin navigations (site editor sub-routes,
template and pattern operations) loaded without the header. The agent
cluster mismatch broke cross-window communication and SharedArrayBuffer
access required for WebAssembly-based client-side media processing in
Chromium 137+.

The block-editor screen gate is replaced by an `upload_files` capability
check, since cross-origin isolation is only needed for users who can
upload media. The existing escape hatch for third-party page builders
that override the block editor via a custom `action` query parameter is
retained.

The front-end preview is intentionally out of scope; DIP remains an
admin-only concern.

See related Gutenberg pull request: WordPress/gutenberg#76662.
The classic-theme home-route guard referenced $screen->id, but moving
the hook to admin_init removed the get_current_screen() lookup, leaving
$screen undefined. Detect the site editor via the global $pagenow
instead, which is available on admin_init.

Add the Core backport changelog entry linking to wordpress-develop#11298.
@adamsilverstein

Copy link
Copy Markdown
Member Author

Core backport: WordPress/wordpress-develop#11298

@adamsilverstein adamsilverstein changed the title Media: Broaden DIP header scope to all admin pages Broaden DIP header scope to all admin pages Jun 27, 2026
@github-project-automation github-project-automation Bot moved this to 🔎 Needs Review in WordPress 7.1 Editor Tasks Jul 8, 2026
@adamsilverstein

Copy link
Copy Markdown
Member Author

Since this change risks some potential plugin breakage in wp-admin due to plugin conflicts - which is difficult to fully test - I'm nervous about backporting to WordPress core and wondering about merging plugin-only for now.

What do you think @andrewserong? We could also leave it out for now until we find an actual use case for it.

@adamsilverstein adamsilverstein moved this from 🔎 Needs Review to 🦵 Punted to 7.2 in WordPress 7.1 Editor Tasks Jul 13, 2026
@adamsilverstein

Copy link
Copy Markdown
Member Author

Punting from 7.1 for now.

@andrewserong

Copy link
Copy Markdown
Contributor

We could also leave it out for now until we find an actual use case for it.

I'd leave it out for now. Because it affects all admin areas, I think wordpress-develop might be a better place to pick it up again in the future rather than in Gutenberg, as it likely needs a bit more core attention that's a bit more beyond the scope of GB.

I.e. a good time to pick it up again might be if/when we look at introducing client-side media processing in the upload flows for core screens.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Feature] Client Side Media Media processing in the browser with WASM [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Document-Isolation-Policy header scope is too narrow, breaking cross-window communication across admin screens

3 participants

Sponsor
SponsoredKunjungi sekarang
Promo