Drag and Drop: Skip sibling insertion check if block is moving within same parent

[yogeshbhutkar]

What, Why & How?

The following condition needs to be updated:

gutenberg/packages/block-editor/src/components/list-view/use-list-view-drop-zone.js

Lines 388 to 390 in 4b39807

	if ( ! candidateBlockData.canInsertDraggedBlocksAsSibling ) {
	return;
	}

Here, the insertion is checked with the help of canInsertDraggedBlocksAsSibling which in turn is determined with the help of canInsertBlock in the following code block:

gutenberg/packages/block-editor/src/store/selectors.js

Lines 1673 to 1676 in 4b39807

	const isLocked = !! getTemplateLock( state, rootClientId );
	if ( isLocked ) {
	return false;
	}

When the lock is not set to Lock Movement, getTemplateLock returns insert which evaluates to True, and early returns False leading to this bug.

If a block is inserted within the same parent to a different position, it shouldn't be counted as an insertion but rather as an internal movement of the block. Hence, checking for this condition does not make sense when the block is moved within the same parent.

Therefore, in the PR, if the block is just moved within the same parent, i.e., if the parent's ID before and after dropping the block remains the same, then we can skip the insertion check as the block is not inserted but rather moved.

Testing Instructions

1. Create a Grid/Row/Column block.
2. Insert some image elements in it.
3. Try locking the Grid/Row/Column block but don't lock the Movement.
4. Notice, that it's possible to move the inner blocks of Grid/Row/Column by both Toolbar Move Buttons and Drag and Drop.

Screenshots or screencast

Before

After

Closes: #67869

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: yogeshbhutkar <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: Mayank-Tripathi32 <[email protected]>
Co-authored-by: pdewouters <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[yogeshbhutkar]

Hi @Mamaduka, can you please review this PR when you get a moment?

[Mamaduka]

Thanks for working on this, @yogeshbhutkar!

I think this only fixes the bug in the List View, but the same issue affects the canvas; we should look for a more general solution.

I've also requested feedback from @talldan, who has more experience in this area.

[yogeshbhutkar]

Thanks for the review, @Mamaduka.

This bug is a little weird in the canvas, the last block cannot be dragged and moved, although, the block before it can. I'll try to look out for possible general solution for this.

Screen.Recording.2025-01-07.at.5.35.51.PM.mov

[Mamaduka]

This bug is a little weird in the canvas, the last block cannot be dragged and moved, although, the block before it can. I'll try to look out for possible general solution for this.

That's probably a separate issue. I think it's being tracked separately, but I can't find it at the moment.

[yogeshbhutkar]

Thanks for letting me know. I'll then wait for @talldan to chime in and help me with the possible general approaches.

[Mayank-Tripathi32]

@yogeshbhutkar
Similar PR: #68297

I had fixed the drag and drop issue with submenu. Might worth checking out.