This is an unlikely fix. The .toBeFocused() check on the next should wait until the button is focused, i.e., should be fine with finding an unfocused button several times before giving up. The failure report looks like this:

2) [chromium] › specs/editor/various/publish-panel.spec.js:11:2 › Post publish panel › should move focus back to the Publish panel toggle button when canceling 
    Error: expect(locator).toBeFocused() failed

    Locator:  locator('role=region[name="Editor top bar"i]').locator('role=button[name="Publish"i]')
    Expected: focused
    Received: inactive
    Timeout:  5000ms

    Call log:
      - Expect "toBeFocused" with timeout 5000ms
      - waiting for locator('role=region[name="Editor top bar"i]').locator('role=button[name="Publish"i]')
        9 × locator resolved to <button type="button" aria-expanded="true" aria-disabled="false" class="components-button editor-post-publish-panel__toggle editor-post-publish-button__button is-primary is-compact">Publish</button>
          - unexpected value "inactive"


      31 |
      32 | 		// Test focus is moved back to the Publish panel toggle button.
    > 33 | 		await expect( publishPanelToggleButton ).toBeFocused();
         | 		                                         ^
      34 | 	} );

Note that when the button failed to be focused, it still has aria-expanded=true attribute. Waiting for aria-expanded=false should fail the same way as waiting for focus. The 9 × locator bit means that Playwright tried 9 times before giving up.

It looks almost like the test fails to click the "Cancel" button at all. It can happen when it is disabled, i.e., the isSavingNonPostEntityChanges selector value is true. This happens when some other entity is saving in the background. Strange.

Yeah, this is an odd, flaky one. Trace logs say that the button is enabled, but the click still fails.

Update: Our a11y way of disabling buttons uses accessibleWhenDisabled, which renders aria-disabled="true" and intercepts click/mousedown with stopPropagation()+preventDefault(), so onClick never fires. This is why the logs were misleading.

@jsnajdr, suspicion was right. I'm going to create PR for this. See #78082.

waiting for locator('role=region[name="Editor publish"i]').locator('role=button[name="Cancel"i]')
locator resolved to <button type="button" class="components-button is-secondary is-compact">Cancel</button>
attempting click action
waiting for element to be visible, enabled and stable
element is visible, enabled and stable
scrolling into view if needed
done scrolling
performing click action
click action done
waiting for scheduled navigations to finish
navigations have finished

It looks almost like the test fails to click the "Cancel" button at all.

Looking at the Playwright trace stored as an action artifact, I see that the test has trouble clicking "Cancel" because the editor-post-publish-panel__slide-in-animation animation is running. The PostPublishPanel is sliding in and the "Cancel" button is moving. That's why the click sometimes fails.

It's very strange because this animation is gated with @media not (prefers-reduced-motion) and Playwright is configured with reducedMotion: 'reduce'. The animation shouldn't run. And yet, as anyone can check themselves by running the test with npm run test:e2e:debug in UI mode, the animation is running. And if you add a background-color: red style to make is visually obvious whether prefers-reduced-motion is respected, then the panel is red! It's also interesting that adding a check in code:

console.log( 'prefers-reduced-motion:', window.matchMedia( 'prefers-reduced-motion' ).matches );

it will log true. And yet the visual output based on CSS will behave like false.

I think this is a Playwright bug, I can reproduce it even with a minimal independent example. I'll look into this further today.