WP 5.7 - Drawer & Modal blocks can't be properly selected in the editor

[acketon]

Drawer Block & Modal Block

In testing these blocks I've found a possible issue. When I click on the block in the editor the block does not always properly become selected and show the block inspector in the sidebar. It looks like it varies depending on where I click. This behavior is different from how it functions in WP 5.4.

It looks like it has to do with some odd choice made in how the drawer & modal blocks handle being selected to show their hidden inner blocks area.

Screen.Recording.2023-03-23.at.1.37.22.PM.mov

A guess, but I think it might have to do with this code in both the Drawer & Modal blocks:
https://github.com/bu-ist/bu-blocks/blob/develop/src/blocks/drawer/drawer.js#L160-L163
This is setting the clientID of the block so that here:
https://github.com/bu-ist/bu-blocks/blob/develop/src/blocks/drawer/drawer.js#L132-L138
in the getEditWrapperProps() a data attribute of data-selected-drawer can be added to the block inside the block editor.

That data attribute appears to only be used in the editor.scss file to show/hide the drawer part of the block or modal part of the modal block: https://github.com/bu-ist/bu-blocks/blob/develop/src/blocks/drawer/editor.scss#L9-L16

If that is all it is doing, perhaps we could just use the is-selected and has-child-selected class of the block to do the same thing. We've done that in other blocks. I'm not sure why it was built this way and if there was a good reason to do it like this. I will say that the Drawer & Modal blocks were probably the first blocks that 10up worked on in this plugin back in 2019 so it could just be due to it's age.

Perhaps back then with the Beta version of Gutenberg a parent block did not get a class of has-child-selected when a child block was selected so a custom attribute was needed to determine when a child block of the Drawer or Modal was actually selected. (so it didn't hide on you when you clicked into a child block)

[sksaju]

@acketon I've tried but was unable to reproduce this issue on my local! which theme are you using?

[acketon]

@sksaju I'm testing it on my upgrade sandbox in this site: https://id-dakota-upgrade.cms-devl.bu.edu/bu-blocks/ which is using our Responsive Framework v2.x.

I recorded another video showing what is happening and comparing it to a WP 5.4 sandbox.

Screen.Recording.2023-03-27.at.10.38.41.AM.mp4

[sksaju]

Thanks, @acketon, I've rechecked and found that my WordPress version automatically got updated to 6.1.1, maybe that's why I couldn't reproduce this issue earlier but now after downgrading the version I can reproduce this on my local. looking into it.

[sksaju]

@acketon This issue might be related to the WP core update, not sure how to fix this yet, this also works on WP 5.8.6 but not on 5.7, is there any chance to use 5.8.6? then I'll ignore it and this issue gets automatically fixed after migrating to 5.8.6

[sksaju]

This is nothing to do with the getEditWrapperProps function as it does not get fired when we click inside the block, something else is happening!

[acketon]

no the plan from IS&T is to upgrade to 5.7 first, then later in the year or next year upgrade to 5.8

[acketon]

@sksaju I did some experimenting and the problem appears to go away when I comment out this call to allowedBlocks(). With that disabled I can select the block reliably.

<InnerBlocks
	//allowedBlocks={ allowedBlocks() }
/>

[sksaju]

This is helpful, Thanks @acketon

[acketon]

I think this might be happening on the <aside> block too. Which also uses the allowedBlocks() component.

[sksaju]

Thanks, @acketon, I've created a PR to fix this issue, please take a look and let me know your feedback

[acketon]

Fixed by upgrading the blocks to Block API 2