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: afercia <afercia@git.wordpress.org>
Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>
Co-authored-by: colinduwe <colind@git.wordpress.org>

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

Noting that the related issue #60299 is a blocker for #60275. @WordPress/gutenberg-core I'd appreciate a review, when you have a chance.

Size Change: +3 B (0%)

Total Size: 1.84 MB

_{compressed-size-action}

Looking into the failing e2e test...

Flaky tests detected in aaee248.
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/13371841317
📝 Reported issues:

• [Flaky Test] should show correct homepage actions based on current homepage or posts page #68892 in /test/e2e/specs/site-editor/homepage-settings.spec.js

The fact some e2e tests intermittently fail and then suddenly pass makes debugging extremely time consuming and a little frustrating. Additionally, debugging locally is often unreliable, at least for me, because some tests fail locally, while they pass on GitHub, with no apparent reason.

For example:

On GH, the test editor/blocks/navigation-frontend-interactivity.spec.js > submenu click on the arrow interactions was failing here. With no apparent reason. I restarted the jobs a few times and was still failing. Now, it passes.
The log hinted to the test failing because of the visitSiteEditor test util failing for some reason but that seems unrelated to the changes in this PR.

Locally, that test passes. But, another test always fails locally for me thus making debugging basically impossible.
Whatever I do, editor/blocks/navigation-frontend-interactivity.spec.js > Overlay menu interactions in Safari (@webkit) always fail.

It's not the first time that I face some tests failing locally and passing on GH and I'm not familiar enough with the testing framework to understand why. Not sure whether I'm missing something or if some special configuration is necessary but `I'd argue the tests should run consistently locally and GH otherwise debugging becomes extremely time consuming if not impossible.

I'd appreciate some feedback from contributors more familiar than me with Playwright. It would be interesting to know if anyona already faced similar issues and whether I'm missing any configuration or steps. Thanks!
Pinging @Mamaduka 🙏🏻 as I know you have a lot of knowledge about Playwright.

Thanks for the ping, @afercia!

That test is super flaky, and I'm also not sure what the exact cause is.

I need to check if removing the "waiting for spinner" condition is safe. If I remember correctly, the spinner and canvas haven't been displayed simultaneously since some recent refactorings.

@WordPress/gutenberg-core what would be the best way to add tests for this? They should:

• Set a theme with a dark background variation e.g. Twenty Twenty-Four.
• Activate that variation e.g. Maelstrom.
• Load the post editor.
• Check the iframe body class attribute contains the CSS class is-dark-theme.
• Same for the Site editor.

@glendaviesnz when you have a chance, I'd appreciate your eyes on this new approach 🙏🏻 to make sure it doesn't introduce other problems like the one fixed in #60550 for Safari.
To my understanding, this new approach should be safe as it doesn't do anything with contentDocument.body.

I have not found any problems with the zoom out, or with any other body classes, in Safari.

Thanks @carolinan for your testing and review.
I'm going to see if I'm able to add a couple e2e tests.

@WordPress/gutenberg-core I'm going to merge this change as it's simple and self-contained. We tested it at our best and didn't notice regressions. If you notice any problems like the one fixed in #60550 for Safari no objections to revert it.