Amp-wp: Removing initial Text block raises error

[westonruter]

To reproduce, start a new story and try to remove the default Text block. Upon doing so, an error is raised:

TypeError: Cannot read property 'name' of null
    at https://wordpressdev.lndo.site/content/plugins/gutenberg/build/edit-post/index.js?ver=1556907891:1146:18
    at arrayMap (https://wordpressdev.lndo.site/core-dev/src/wp-includes/js/dist/vendor/lodash.js?ver=4.17.11:639:23)
    at map (https://wordpressdev.lndo.site/core-dev/src/wp-includes/js/dist/vendor/lodash.js?ver=4.17.11:9556:14)
    at PluginBlockSettingsMenuGroupSlot (https://wordpressdev.lndo.site/content/plugins/gutenberg/build/edit-post/index.js?ver=1556907891:1145:70)
    at renderWithHooks (https://wordpressdev.lndo.site/content/plugins/gutenberg/vendor/react-dom.165d5c53.js:13027:18)
    at updateFunctionComponent (https://wordpressdev.lndo.site/content/plugins/gutenberg/vendor/react-dom.165d5c53.js:14716:20)
    at beginWork (https://wordpressdev.lndo.site/content/plugins/gutenberg/vendor/react-dom.165d5c53.js:15726:16)
    at performUnitOfWork (https://wordpressdev.lndo.site/content/plugins/gutenberg/vendor/react-dom.165d5c53.js:19401:12)
    at workLoop (https://wordpressdev.lndo.site/content/plugins/gutenberg/vendor/react-dom.165d5c53.js:19441:24)
    at renderRoot (https://wordpressdev.lndo.site/content/plugins/gutenberg/vendor/react-dom.165d5c53.js:19524:7)

[westonruter]

For some reason, selectedBlocks passed to PluginBlockSettingsMenuGroupSlot is [null]:

[miina]

Note: This issue seems to occur with other blocks as well, including core blocks, e.g. Image block.

If there is just one block on one Page then trying to remove this one block from the Toolbar causes the editor to break.

[miina]

I was looking into this issue and it seems that it might be an issue with Gutenberg. It doesn’t seem that removing a block via Toolbar is handled correctly -- although the block is removed then it’s still trying to render the Toolbar for the currently selected block and since it actually doesn't exist then this causes an issue.

It can also be seen in the default editor — when removing a block via Toolbar, the block should be removed and the Toolbar closed (since that block doesn't exist anymore), however, since it is still trying to render the Toolbar, then the toolbar for the newly selected block (the previous block from the removed block) is rendered instead with the settings menu open (the three dots menu). It seems like since by default a Paragraph is always forced to exist then no errors occur — a freshly created paragraph will always appear, again, with the menu already open. To see this, go to the default editor, add an Image block, then add a Paragraph block after the Image block, and then remove the Paragraph block via Toolbar -- you'll see that the Toolbar will render already open.

Here are also some related issues which might hint that the removal of a block might not be properly handled:

• https://github.com/WordPress/gutenberg/issues/13276
• https://github.com/WordPress/gutenberg/issues/3221 (got resolved for BlockMover)

We could add a workaround by doing the following:

• Check if the story includes just one page without any child blocks (e.g. within subscribe())
• If that’s true then force this one Page to be selected.

This will avoid the editor breaking, resulting in similar “odd default” behavior of rendering the Toolbar for the remaining Page block, already open, after deleting the last child block from the Page. Also, this would force a Page block being selected if it's the only block, tested it a little bit and it doesn't seem to cause issues at first glance.

It would be ideal to fix this within Gutenberg (if the issue comes from there) but considering the timeframe then might be good to use a workaround meanwhile. Perhaps you have an alternative idea, @swissspidy?

cc @westonruter

[miina]

Actually, it looks like the issue occurs generally when removing the last block from a Page, even if there are multiple pages. The reason is that a new block is not selected after removing the last block from a Page.

In this case, the parent of the deleted block should be enforced selected after block removal, perhaps there's an easy/solid way of detecting the parent of the just removed block, not sure.

[miina]

(Created an issue for that meanwhile: https://github.com/WordPress/gutenberg/issues/15458)

[swissspidy]

Opened a PR for that upstream: https://github.com/WordPress/gutenberg/pull/15543

[swissspidy]

Moving to _Ready for Review_ as one could test and review the upstream PR at https://github.com/WordPress/gutenberg/pull/15543, potentially speeding up the process of that fix being merged.

[swissspidy]

@westonruter @kienstra Can you please test https://github.com/WordPress/gutenberg/pull/15543 as well to see if everything works as expected?

[kienstra]

Sure, @swissspidy!

[miina]

Thanks for testing, @kienstra.

@swissspidy I'm moving this into ready for QA until it gets merged since it has been reviewed / tested from our side.

[csossi]

Still having a prob here. tried to remove the initial default text block and got this:

[westonruter]

This would be expected since the patched version of Gutenberg has not been deployed.

[miina]

@csossi I'll assign the issue to you once it'll be ready for QA, thank you!

[swissspidy]

Yay, the upstream PR has finally been merged after some discussions and adding tests. It should ship with Gutenberg 5.8, which is due by Monday, May 27, 2019.

[swissspidy]

5.8 RC 1: https://github.com/WordPress/gutenberg/releases/tag/v5.8.0-rc.1

[swissspidy]

@csossi This should now be fixed on the staging area, please test again! 🙂

[csossi]

Verified in QA