Description

If a block's parent is set to a 'disabled' block editing mode, with the block itself set to a 'default' block editing mode, then the block incorrectly displays as 'locked' to the user, even allowing them to unlock the block (which does nothing as users cannot modify block editing modes).

The reason for this is that the lock feature (via the useBlockLock hook) checks for locking by looking at the canMoveBlock and canRemoveBlock selectors. These return false when the parent block is disabled.

The tricky part is that these selectors are correct, for example I'm sure canRemoveBlock is used in places to prevent inner blocks of disabled blocks being removed, and that's good. I think the lock feature is using them incorrectly, it should perhaps instead have separate selectors that reason about what the user is capable of.

Step-by-step reproduction instructions

1. Create a post with a single paragraph that has some text in it.
2. Copy the client id of the paragraph (I usually 'Inspect element' and then grab the value of the data-block attribute. )
3. In the console run the following snippet, on the second line use the client id you copied in place of 'paste-copied-client-id-here':

wp.data.dispatch( 'core/block-editor' ).setBlockEditingMode( '', 'disabled' );
wp.data.dispatch( 'core/block-editor' ).setBlockEditingMode( 'paste-copied-client-id-here', 'default' );

4. Observe that the paragraph shows the lock icon in the toolbar, and even allows unlocking, but unlocking does nothing

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure