Stop keeping stale controlled blocks after reset (test)#76591
Stop keeping stale controlled blocks after reset (test)#76591
Conversation
|
Size Change: 0 B Total Size: 8.75 MB ℹ️ View Unchanged
|
|
Flaky tests detected in 228c69d. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23202114110
|
|
@youknowriad A question related to this PR: what was the idea behind selection and block state restoration in #75371 and friends? When navigating from one editor page to another, you'll see a lot of The approach to fix this bug will depend on the answer. If we want to keep the |
|
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. |
In this PR I managed to isolate a bug described in #76310 (comment) (the second one). Sometimes the
core/block-editorstate ends up with block tree whereorderandparentssay that there are no child blocks, buttreecontains child blocks.At this moment the PR has only a failing unit test that isolates the bug.
The key events and problems are:
resetBlocks( [] )action leaves staletreerecords behind, although they are no longer relevant. Namely there is thecontrolled||chickentree entry although thechickenblock is completely gone from the tree.setHasControlledInnerBlocks( 'chicken', false )afterwards, the action fails (inwithResetControlledBlocks) to reset the inner blocks to empty array. BecauseinnerBlockOrderis undefined. Then the stalecontrolled||chickenrecord survives.I'm not sure about the fix yet, but the most suspicious place is
withBlockResetwhere it handlesRESET_BLOCKSand copies the entire oldstate.tree. We shouldn't do that, we should cherry-pick only the records that are still relevant.fyi @youknowriad @talldan