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

Activity

1. mbgoins-create

   added

   [Type] BugAn existing feature does not function as intendedAn existing feature does not function as intended

   on Sep 22, 2026
2. talldan

   added

   Needs TestingNeeds further testing to be confirmed.Needs further testing to be confirmed.

   [Feature] Drag and DropDrag and drop functionality when working with blocksDrag and drop functionality when working with blocks

   on Sep 23, 2026
3. SainathPoojary commented on Sep 23, 2026

   

   SainathPoojary

   on Sep 23, 2026

   Last edited by SainathPoojary

   Member

   More actions

   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

   👀React with 👀2Reacted by Mustafa Bharmal and Dev Mehta
4. dpmehta commented on Sep 24, 2026

   

   dpmehta

   on Sep 24, 2026

   Last edited by dpmehta

   Contributor

   More actions

   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.

   👀React with 👀1Reacted by Mustafa Bharmal
5. SainathPoojary

   removed

   Needs TestingNeeds further testing to be confirmed.Needs further testing to be confirmed.

   on Oct 8, 2026
6. mtias

   added a commit that references this issue on Oct 23, 2026

   Block editor: link the changelog entry to the pull request

   ...

   a16698d