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>

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

Size Change: 0 B

Total Size: 7.92 MB

_{compressed-size-action}

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

• [Flaky Test] post title and content are editable and blocks can be inserted #77720 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js

@Mamaduka I was also looking at this in the last few days, and also noticed that isSavingNonPostEntityChanges is a suspect, but my prediction is that this is not the real fix and that the test will continue to be flaky 🙂

To trigger isSavingNonPostEntityChanges we'd need to be doing some very special things, like saving a reusable block. But here we're saving a very simple post with one paragraph block.

My findings described in https://github.com/WordPress/gutenberg/pull/77893/changes#r3217213285 indicate that there is a slide-in animation in progress when the test tries to click "Cancel". On a moving button. Very strange, as animations should be disabled with prefers-reduced-motion.

Thanks for additional info, @jsnajdr! I’ve not even considered animations because of that global plugin.

This seem to reduce flakiness of the test, but that might be due extra check just giving animations enough time to finish.

There’s no harm in this change, IMO.

There’s no harm in this change, IMO.

I agree, there's no harm checking if the button is enabled. But #77721 was automatically reopened just 6 hours after closing. I'm not sure if this can be caused by a PR branch that is still based on an unfixed trunk.

Reported a Playwright bug here: microsoft/playwright#40772 Not sure if it's really the cause of this flaky test, but definitely a bug.

@Mamaduka This patch, waiting for the Cancel button to be enabled, didn't fix the flaky test. And neither did @danluu's AI fuzzed #77893, which waits for the Publish button to be aria-enabled=false. We still get failure reports all the time.

But I think I found the cause, even I don't understand yet how it happens. If you look at this video from one of the failed runs, notice that the "Cancel" button is enabled, then gets disabled for a brief moment, and then gets enabled again:

That means that isSavingNonPostEntityChanges is indeed true for a moment. But I don't understand at all what could be possibly saving.

The wait for cancelButton.toBeEnabled() doesn't really work, because initially it is enabled. But at the time when the test wants to click, it's disabled.

@jsnajdr do you think it could be RTC related? Some other flaky test (like classic block) I tried to look into became more unstable very recently and only major change we have to data store is RTC.

do you think it could be RTC related

Maybe, but does RTC possibly affect isSavingNonPostEntityChanges? When I asked Cursor to analyze possible causes, the conclusion is that AI also doesn't have any idea.

Some other flaky test (like classic block) I tried to look into

I was looking into the failure where classic "convert to block" loses selection after undo and there is no block toolbar to click. That could be possibly related to RTC, because RTC manages the undo stack which also does the selection restoration job. But I still understand RTC only very superficially.