Performance Tests: Wait for editor canvas before media-upload inserts#78541
Closed
ellatrix wants to merge 1 commit into
Closed
Performance Tests: Wait for editor canvas before media-upload inserts#78541ellatrix wants to merge 1 commit into
ellatrix wants to merge 1 commit into
Conversation
Each media-upload test currently does `admin.createNewPost()` directly followed by `editor.insertBlock(...)`. The post-editor preload kickoff (#78508) defers `setupEditor`'s `SET_EDITED_POST` dispatch past page load, so the block insertion can land on a block-editor store that hasn't bound to the post entity yet — the canvas ends up empty and the subsequent `toBeVisible` assertion times out. Wait for the editor canvas iframe body to render before the iteration loop. That signal only fires once `<BlockEditorProvider>` has mounted, which guarantees the block-editor store is bound. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. 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.98 MB ℹ️ View Unchanged
|
|
Flaky tests detected in 47631d0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26272079291
|
Member
Author
|
Superseded by #78546, which fixes the root cause — the malformed user-global-styles preload entry on WP 6.9 for classic themes. With #78546 applied, all four |
jsnajdr
approved these changes
May 22, 2026
jsnajdr
left a comment
jsnajdr
left a comment
Member
There was a problem hiding this comment.
Cool, it's always a good idea to wait for the UI that we want to work with. Not doing so is a cause of many flaky tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Make the media-upload perf spec wait for the editor canvas iframe to mount before dispatching
insertBlock. Each test in the spec previously calledadmin.createNewPost()immediately followed byeditor.insertBlock(...), racing the editor's initialization.Why?
The trunk "Performance Tests" job has been failing on every push since #78508 merged (e.g. run 26248025334) with the same shape:
expect(imageBlock).toBeVisible()timing out and the canvas screenshot showing an empty editor.Root cause:
root.render.initializeEditornow awaits aPromise.all([...])of resolvers before mounting React.<EditorProvider>'ssetupEditoreffect — which dispatchesSET_EDITED_POSTand binds the block-editor flow to the post entity — only fires after the kickoff settles.editor.insertBlockonly waits forwindow.wp.blocks && window.wp.data. Both are available within ~10 ms of page load, well before the kickoff settles. The helper then dispatcheswp.data.dispatch('core/block-editor').insertBlock(...)against a block-editor store that hasn't yet been bound to the post's edited entity.<BlockEditorProvider>finally mounts, it resets the block-editor store from the entity's blocks (empty post) — overwriting the pre-mount insertion. Canvas stays empty.Other perf specs (e.g.
post-editor) avoid the race by accident: they have aloadBlocksForLargePost()call betweencreateNewPost()andinsertBlock(), and that step'sparse(largeHtml)happens to take long enough for the editor to finish mounting. The media-upload spec has nothing betweencreateNewPost()andinsertBlock().The failure shows up on the trunk job specifically (rather than the PR job) because the trunk job pins
--wp-version 6.9. On that environment the kickoff settles slightly later, deterministically pushingsetupEditorpast the test's 5-secondtoBeVisibletimeout.How?
runUploadIterations(the helper used by the three single-image tests) and the "Batch upload 5 images" test each get one extra line right aftercreateNewPost():```js
await editor.canvas.locator( 'body' ).waitFor();
```
The
editor.canvasiframe is only rendered by<BlockEditorProvider>after mount, so waiting on its body to appear is the smallest reliable readiness signal. Two call sites cover all four tests in the file.Testing Instructions
Reproduce the failure on trunk:
```sh
npm exec --no release-cli -- perf "$(git rev-parse trunk)" dae102a --tests-branch "$(git rev-parse trunk)" --wp-version 6.9 -c
```
The
media-uploadsuite fails the four tests inMedia Upload Performance.Run the same command against this branch — all four tests pass.
History
🤖 Generated with Claude Code