Group block no longer can be edited upon drag & drop in editor window

[mbgoins-create]

Description

This was reported by a user of our WordPress service where they would accidentally grab a group block within the editor window and move it (similar to trying to move blocks within the List View); however upon releasing their left mouse button the group block itself would become 'locked' and you could no longer select content within it including editing text within a paragraph block.

I have been able to replicate this error using our custom WordPress theme as well as the Twenty Twenty-Five theme in a local install, as well as on our servers.

There was a secondary issue that is harder to reproduce, which has the selected group block shrinking and remaining in that shrunken view. This is all reset upon doing a refresh of the browser window.

Step-by-step reproduction instructions

1. Create content (specifcally, several paragraph blocks or use a pattern to add that content) and group it together. Set your group block Align setting to be Full width.
2. Within the editor area, click the area of the group block outside of your text so you get the 'grab handle' hand icon. That will select the group block.
3. Drag the group block around within your editor window and then release it. Please note that this isn't an exact science and it takes a few tries to bug it out. Once is sometimes not enough.
4. Once you release your mouse button, check to see if you can select any content (such as text) within that group block, and attempt to add or delete a character.
5. What you will experience when the bug hits is that that specific group block is no longer editable.

Screenshots, screen recording, code snippet

I have created a screen recording of recreating this bug using the WordPress Playground (https://playground.wordpress.net/).

https://mediaspace.wisc.edu/media/Group+Block+Bug/1_g8isdgwy

Environment info

• Using WordPress Playground (https://playground.wordpress.net/), which is using WordPress version 7.1.2.
• Using the Twenty Twenty-Five theme
• Using Microsoft Edge (Version 153.0.4234.48 (Official build) (64-bit)) - thought this has been recreated using Firefox and Chrome in most recent versions.
• Using Windows 11, though coworkers have also recreated it using MacOS.

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

[SainathPoojary]

Thanks for reporting the issue, I was able to reproduce this issue following the steps described as well.

Here is a screen recording demonstrating the behavior on my end: Video

Environment Tested:

• WordPress: 7.1.2 (via WordPress Playground)
• PHP: 8.3.33 (Server: PHP.wasm)
• Database: WP_MySQL_On_SQLite
• Browser: Google Chrome 154.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• Plugins: Test Reports 1.3.1

[dpmehta]

I looked into the issue and tried to find out the root cause for the issue and i am adding my findings below.

Root Cause Analysis: Group Block Paragraph Uneditable After Drag & Drop

When a user drags and drops a Group block, releases it after moving it around, and attempts to edit the inner paragraph, the paragraph and other inner content blocks become completely uneditable.

1. Comparison: Baseline (Working) vs. Bug (Reproduced) State

The table below compares two states: the first represents the clean state prior to bug reproduction, while the second illustrates the result after the bug has been reproduced (that is, following the drag and drop action).

Property	Baseline State (Working)	Bug State (After Drag & Drop)	Why It Changed
Paragraph isContentEditable	true	false / non-interactive	RichText editing host deactivated
Paragraph contenteditable	"true"	"false"	RichText receives inactive editing mode
Paragraph Selection	is-selected	Not selected / deselected	Drag cleared browser & store selection
Group Block pointer-events	auto	none (residual inline style or inherited)	onDragStart sets pointerEvents = 'none' in over(), cleanup fails
Inner Group class	is-editing-disabled	is-editing-disabled	contentOnly mode derived for non-content blocks
Child Outline	Normal	has-editable-outline	Section click handler flashes outline instead of entering edit

---

2. Detailed Root Cause Breakdown

The issue is caused by a combination of two distinct flaws in Gutenberg's drag-and-drop and section block architectures:

Cause 1: Direct DOM Mutation & Stale Cleanup in onDragStart (The Residual Drag State Bug)

The drag-and-drop mechanism in use-selected-block-event-handlers.js directly mutates DOM styles on the dragged block:

gutenberg/packages/block-editor/src/components/block-list/use-block-props/use-selected-block-event-handlers.js

Lines 186 to 202 in 72e0cc4

	node.style.position = 'relative';
	node.style.top = `${ 0 }px`;
	node.style.left = `${ 0 }px`;
	const originX = event.clientX - rect.left;
	const originY = event.clientY - rect.top;
	// Scale everything to 200px.
	const dragScale = rect.height > 200 ? 200 / rect.height : 1;
	node.style.zIndex = '1000';
	node.style.transformOrigin = `${ originX * inverted }px ${
	originY * inverted
	}px`;
	node.style.transition = 'transform 0.2s ease-out';
	node.style.transform = `scale(${ dragScale })`;
	node.style.opacity = '0.9';

The cleanup function end() is registered on the iframe's ownerDocument:

gutenberg/packages/block-editor/src/components/block-list/use-block-props/use-selected-block-event-handlers.js

Lines 259 to 279 in 72e0cc4

	function end() {
	ownerDocument.removeEventListener( 'dragover', dragOver );
	ownerDocument.removeEventListener( 'dragend', end );
	ownerDocument.removeEventListener( 'drop', end );
	ownerDocument.removeEventListener( 'scroll', over );
	for ( const [ property, value ] of Object.entries(
	originalNodeProperties
	) ) {
	node.style[ property ] = value;
	}
	clone.remove();
	node.id = id;
	dragElement.remove();
	stopDraggingBlocks();
	document.body.classList.remove(
	'is-dragging-components-draggable'
	);
	ownerDocument.documentElement.classList.remove(
	'is-dragging'
	);
	}

Why this breaks:

1. Stale Node Reference on Block Reorder:
   When the block is dragged and dropped to another position , useOnBlockDrop dispatches moveBlocksToPosition(). React re-renders the block tree. node inside end() holds a reference to the previous DOM instance or stale DOM node.

2. Missing dragend / drop on Drag-Around:
   When the user moves the block around the canvas for 5–10 seconds and releases the mouse:

   • If the cursor is over an invalid drop target, or dropped back onto itself, the native HTML5 drop event does not fire.
   • If the cursor crosses the iframe boundary (into admin bar, toolbar, or sidebar) during mouseup, the dragend event on ownerDocument is frequently missed or swallowed.

3. No Cleanup in Hook Unmount:
   useEventHandlers unmounts whenever isSelected, isZoomOut, or hasMultiSelection changes. Its cleanup function only removes keydown, dragstart, and dblclick from node. It never calls end() and never cleans up the ownerDocument listeners or residual styles.

4. Result: node.style.pointerEvents = 'none' and node.style.transform = 'scale(...)' remain permanently active on the block. Clicks pass completely through the element, making it impossible to click into the text or select inner blocks.

---

Cause 2: Unsynced Pattern Section Trapping & Overlay Click Interception

Even when inline drag styles are restored, the block editor enters a Section Interaction Trap:

1. Pattern Detection as a Section:
   In private-selectors.js , any group with metadata.patternName is classified as a Section Block (isSectionBlock === true).

2. Editing Mode Architecture for Unsynced Patterns:
   In reducer.js

   • The inner group container receives blockEditingMode: 'disabled' (is-editing-disabled with pointer-events: none).
   • The paragraph and heading receive blockEditingMode: 'contentOnly'.

3. Click Interception by useFlashEditableBlocks:
   In use-block-props/index.js, section blocks mount useFlashEditableBlocks

gutenberg/packages/block-editor/src/components/use-flash-editable-blocks/index.js

Lines 43 to 55 in 72e0cc4

	if ( event.defaultPrevented ) {
	return;
	}
	event.preventDefault();
	flashEditableBlocks();
	};
	element.addEventListener( 'click', handleClick );
	return () => element.removeEventListener( 'click', handleClick );
	},
	[ isEnabled ]
	);
	}

4. RichText Deactivation:
   At the start of onDragStart, selection.removeAllRanges() completely destroys the browser text selection. After the drag operation, the outer pattern block is the selected block in the Redux store.
   Because the inner group container has pointer-events: none and the outer pattern intercepts clicks, single-clicking into the pattern merely triggers the section outline animation (has-editable-outline), preventing focus from landing directly on the paragraph's RichText element. With no focus and no block selection, RichText renders with contenteditable="false".

Open for suggestions and confirmation regarding above findings.