Describe the bug
When the resetBlocks action is dispatched, selection state isn't updated accordingly, which can cause an incorrect selection state.
This can cause issues when using the top toolbar option, a ghost toolbar for the since removed block is displayed, which when clicked results in an error being thrown.
This was first noticed in the Navigation Menu page that's being built - #21340 (review).
In that page, the entire list of blocks can be changed by the BlockEditorProvider, which internally uses the resetBlocks action.
To reproduce
Steps to reproduce the behavior:
- Enable the Top Toolbar option
- Add a paragraph with some text to a post and ensure it stays selected so that the block toolbar is shown at the top
- In the browser dev tools open up the console and execute the following to reset blocks:
wp.data.dispatch('core/block-editor').resetBlocks([]);
- Observe in the top toolbar the block movers and block settings menu are still displayed.
- Click the settings menu. Notice that the editor crashes.
Expected behavior
The toolbar is no longer shown if a block no longer exists (and internally, selection state is cleaned up appropriately.)
Additional Info
I originally tried a fix for this in #21371.
Describe the bug
When the resetBlocks action is dispatched, selection state isn't updated accordingly, which can cause an incorrect selection state.
This can cause issues when using the top toolbar option, a ghost toolbar for the since removed block is displayed, which when clicked results in an error being thrown.
This was first noticed in the Navigation Menu page that's being built - #21340 (review).
In that page, the entire list of blocks can be changed by the
BlockEditorProvider, which internally uses theresetBlocksaction.To reproduce
Steps to reproduce the behavior:
Expected behavior
The toolbar is no longer shown if a block no longer exists (and internally, selection state is cleaned up appropriately.)
Additional Info
I originally tried a fix for this in #21371.