Upgrade Playwright to v1.61

[Mamaduka]

What?

Upgrade Playwright to v1.61.

What's new?

https://playwright.dev/docs/release-notes#version-160
https://playwright.dev/docs/release-notes#version-161

I think new page.locator('#dropzone').drop could be useful for our tests. I'll start looking into migrations as a follow-up. The new description option could also be handy.

Testing Instructions

• Run any e2e test locally; the command should download new browsers and run the test successfully.
• CI checks are green.

[jsnajdr]

Good idea, should cause no trouble. The other day I did an upgrade from 1.58 to 1.59 locally, in an attempt to find a bug, but never committed it as a PR.

[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: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: jsnajdr <jsnajdr@git.wordpress.org>
Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: aduth <aduth@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: +121 B (0%)

Total Size: 7.61 MB

📦 View Changed

Filename	Size	Change
build/scripts/editor/index.min.js	489 kB	+121 B (+0.02%)

_{compressed-size-action}

[Mamaduka]

It looks like previews end up with stale windows in the latest Chrome and DIP enabled. Pushed some test code for confirmations.

Here's the finding from Claude's debug sessions:

Summary

Playwright 1.60 ships Chrome for Testing 148 (1.58 used 145). The failing e2e tests aren't a test-infra issue — they're surfacing a Chromium 148 regression in Document-Isolation-Policy: isolate-and-credentialless (DIP), which Gutenberg sends on editor screens for Chromium ≥137 to get cross-origin isolation.

Proven by toggling the gutenberg_use_document_isolation_policy filter on the same Chrome 148:

Cluster	DIP on (default)	DIP off
Preview / block-context (window.open('', 'wp-preview-X') reuse)	❌ stale tab / waitForNavigation hangs	✅ pass
Client-side media processing	❌ silent server fallback	⏭️ skip (CSM needs isolation)

• Preview: under DIP, Chrome 148 no longer re-navigates a reused named popup → preview shows stale content. DIP's spec says popups should keep working, so this is a genuine browser regression (closest public match: crbug 336222177). Likely affects real Chrome 148 users, not just CI.
• CSM: same header is what enables crossOriginIsolated; a second 148 regression in the isolated/credentialless runtime makes the transcode silently fall back.
• The Chrome 146/147/148 release notes document none of this.

**Playwright 1.60 ships Chrome for Testing 148** (1.58 used 145). The failing e2e tests aren't a test-infra issue — they're surfacing a **Chromium 148 regression in `Document-Isolation-Policy: isolate-and-credentialless`** (DIP), which Gutenberg sends on editor screens for Chromium ≥137 to get cross-origin isolation.

Proven by toggling the gutenberg_use_document_isolation_policy filter on the same Chrome 148:

Cluster	DIP on (default)	DIP off
Preview / block-context (window.open('', 'wp-preview-X') reuse)	❌ stale tab / waitForNavigation hangs	✅ pass
Client-side media processing	❌ silent server fallback	⏭️ skip (CSM needs isolation)

• Preview: under DIP, Chrome 148 no longer re-navigates a reused named popup → preview shows stale content. DIP's spec says popups should keep working, so this is a genuine browser regression (closest public match: [crbug 336222177](https://issues.chromium.org/issues/336222177)). Likely affects real Chrome 148 users, not just CI.
• CSM: same header is what enables crossOriginIsolated; a second 148 regression in the isolated/credentialless runtime makes the transcode silently fall back.
• The Chrome 146/147/148 release notes document none of this.

[Mamaduka]

I guess we can wait until the next release and see if the issue is fixed in the next Chrome upgrade

cc @adamsilverstein, just in case you've seen any similar reports.

[manzoorwanijk]

Peer dependency should usually be the lowest supported version.

Also, IMHO, this peer dep here should be made optional, otherwise it breaks in strict peer deps mode for consumers.

[Mamaduka]

What's your recommendation?

[manzoorwanijk]

Leave this unchanged and add the updated version as a dev dependency, as the package uses it but doesn't declare it and it receives the dependency from hoisting.

gutenberg/packages/scripts/config/playwright.config.js

Line 5 in 229c4d2

const { defineConfig, devices } = require( '@playwright/test' );

[manzoorwanijk]

Add this to peerDependenciesMeta below

"@playwright/test": {
	"optional": true
},

[Mamaduka]

Looking at the Git history, we've been bumping these versions alongside others. I don't remember exactly, but I think there were some version mismatches in the past on wordpress-develop.

P.S. I'm not against making those changes, mostly was double-checking previous updates.

[manzoorwanijk]

Yes, but it's better to go with best practices.

[manzoorwanijk]

CCing @jsnajdr and @aduth for their opinion.

[aduth]

From my perspective, the peer dependency should be as wide as we can possibly allow based on what we actually need to use from this package or are fearful could break in how we use in future versions, even * or >=1. As best I can tell, that's whatever version provides a /cli export that accepts as 'test' argument and config flags and returns a 0 or non-0 status code, which is probably... all of them, forever? (i.e. *) We could add an upper bound like <= 2 or ^1 if we worry about those expectations breaking in a future major version.

The advantage being that this is a lot less annoying for downstream consumers. Why should someone have to bump their @playwright/test when upgrading @wordpress/scripts, if we're not actually doing anything in @wordpress/scripts that needs that newer version?

That's not to say we don't want to be using the same, consistent version across Gutenberg and/or wordpress-develop, but that's a project-level concern. We are our own consumer. So defining devDependencies with the higher version number makes sense so that we are using the one, newer version that has the new feature we want to use.

[Mamaduka]

Addressed this in 515286a. Let me know what you think.

[manzoorwanijk]

Heads up: Following #79221, we will need to update the dependency in root package.json as well.

[Mamaduka]

It looks like Chrome and DIP issues still exist even after the recent Chromium version bump in Playwright - #78632 (comment).

That's a blocker for this update, until those issues are tested and resolved manually :(

[jsnajdr]

I'm afraid that the Document-Isolation-Policy is a real Gutenberg bug that we'll need to address. The Playwright update merely surfaces it, by virtue of installing a newer Chrome.

When opening a preview (in openPreviewWindow) we do three steps:

• window.open a new named tab, potentially reusing the already opened one.
• writeInterstitialMessage( previewWindow.document ) uses the ancient document.write to render an animated WP logo while the preview is loading.
• previewWindow.location = link forces a reload of the preview, with latest changes.

The code that crashes is the previewWindow.document access. If you comment out the writeInterstitialMessage call, the e2e test will be green again. Document-Isolation-Policy isolates the two windows (editor and preview) from each other, even if they are same-origin. And window.document is one of the things you can't touch any more. We'll have to write the interstitial in some less direct way, e.g., the preview window hosting the interstitial-writing script and receiving a message from the opener.

The https://issues.chromium.org/issues/336222177 bug is not really that related. It's about window.open not reusing the same tab, or window.location setter failing to navigate. None of that happens for us, our issue is the window.document access. Frankly this is fairly typical LLM debugging output, it's good at pointing you in the right direction, but there is often some subtle error, and a human judgment and review is needed to walk the last mile.

[jsnajdr]

Locally I'm able to fix the preview window error by adding these two lines before writeInterstitialMessage:

previewWindow.location = 'about:blank';
await new Promise( ( r ) => setTimeout( r, 100 ) );
writeInterstitialMessage( previewWindow.document );

The point is to reset the preview window location to about:blank because on this location the synchronous document access still works. That's why the first attempt to open the preview succeeds. Only the second one fails.

The 100ms wait is there to wait until the window really loads the new location. We can't add event listeners (load) to the window, so we need to wait. setTimeout( 0 ) is not long enough, but 100ms works.

If only we could tidy up this patch and make it production-ready, it would also fix the issue.

[adamsilverstein]

I'm afraid that the Document-Isolation-Policy is a real Gutenberg bug that we'll need to address.

Catching up here... DIP shouldn't be active on previews, are you seeing it active there? If so, maybe we missed something or something changed? Are there steps to reproduce this manually? is this for previews in a new tab pr inline?

[jsnajdr]

DIP shouldn't be active on previews, are you seeing it active there?

DIP is active only on the main editor tab, on the preview tabs it's not active. But that's enough to put both tabs into different "agent clusters", and they become isolated from each other. Like if they were cross-origin.

Are there steps to reproduce this manually?

Yes, it's very straighforward:

1. Edit a post
2. Open a preview by clicking "Preview in new tab" in the "View" menu
3. Make edits to the post
4. Click "Preview in new tab" again.

It's supposed to save the latest edits and update the existing preview tab with new content.

But the actual result is that the tab still shows the old content, and in console there is a security error that the preview tab's previewWindow.document can't be accessed.

[adamsilverstein]

@jsnajdr - Merging in #79495 into this PR will bring CI here green. It includes the preview fix as well as a bunch of follow up client-side media test fixes, see the ticket description for details.

[adamsilverstein]

Tests should go green after aade9a4

[github-actions]

Flaky tests detected in 48f9b48.
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/28495089642
📝 Reported issues:

• [Flaky Test] activate block theme when live previewing in edit mode #77712 in /test/e2e/specs/site-editor/activate-theme.spec.js

[manzoorwanijk]

Thank you for fixing the peer deps

[manzoorwanijk]

Since ESLint doesn't catch this yet, we forgot to add @wordpress/vips to the dev dependencies.

[Mamaduka]

I have a small follow-up PR for locator.drop and will include it there.

[aduth]

Since ESLint doesn't catch this yet

I might have expected this to have been caught after #79703, which was merged a few hours earlier than this one. Maybe it's the require.resolve specifically that isn't checked (vs. require), or maybe #79718 will improve this.

[aduth]

It didn't occur to me this is the same issue as @manzoorwanijk already flagged at #79703 (comment) , i.e. the import plugin doesn't check require.resolve.

[aduth]

Although I also find this code a little strange to begin with, like a very complex series of hoop-jumping to avoid defining wasm-vips as a dependency of @wordpress/e2e-tests ? Or maybe we need a way of allowing individual packages to define E2E specs so this could live in @wordpress/vips ?