Editor: Fix block highlight rendering after block is moved

packages/block-editor/src/components/block-toolbar/utils.js

@@ -6,15 +6,11 @@ import { noop } from 'lodash';
  * WordPress dependencies
  */
 import { useDispatch } from '@wordpress/data';
-import { useState, useRef, useEffect, useCallback } from '@wordpress/element';
+import { useState, useRef, useEffect } from '@wordpress/element';
 
-const {
-	clearTimeout,
-	requestAnimationFrame,
-	cancelAnimationFrame,
-	setTimeout,
-} = window;
-const DEBOUNCE_TIMEOUT = 250;
+const { clearTimeout, setTimeout } = window;
+
+const DEBOUNCE_TIMEOUT = 200;
 
 /**
  * Hook that creates a showMover state, as well as debounced show/hide callbacks.
@@ -169,8 +165,6 @@ export function useShowMoversGestures( {
 	};
 }
 
-let requestAnimationFrameId;
-
 /**
  * Hook that toggles the highlight (outline) state of a block
  *
@@ -181,28 +175,13 @@ let requestAnimationFrameId;
 export function useToggleBlockHighlight( clientId ) {
 	const { toggleBlockHighlight } = useDispatch( 'core/block-editor' );
 
-	const updateBlockHighlight = useCallback(
-		( isFocused ) => {
-			toggleBlockHighlight( clientId, isFocused );
-		},
-		[ clientId ]
-	);
+	const updateBlockHighlight = ( isFocused ) => {
+		toggleBlockHighlight( clientId, isFocused );
+	};
 
 	useEffect( () => {
-		// On mount, we make sure to cancel any pending animation frame request
-		// that hasn't been completed yet. Components like NavigableToolbar may
-		// mount and unmount quickly.
-		if ( requestAnimationFrameId ) {
-			cancelAnimationFrame( requestAnimationFrameId );
-		}
-		return () => {
-			// Sequences state change to enable editor updates (e.g. cursor
-			// position) to render correctly.
-			requestAnimationFrameId = requestAnimationFrame( () => {
-				updateBlockHighlight( false );
-			} );
-		};
-	}, [] );
+		return () => toggleBlockHighlight( clientId, false );
+	}, [ clientId ] );
 
 	return updateBlockHighlight;
 }

packages/block-editor/src/components/navigable-toolbar/index.js

@@ -35,11 +35,27 @@ function focusFirstTabbableIn( container ) {
 }
 
 function useIsAccessibleToolbar( ref ) {
+	/*
+	 * By default, we'll assume the starting accessible state of the Toolbar
+	 * is true, as it seems to be the most common case.
+	 *
+	 * Transitioning from an (initial) false to true state causes the
+	 * <Toolbar /> component to mount twice, which is causing undesired
+	 * side-effects. These side-effects appear to only affect certain
+	 * E2E tests.
+	 *
+	 * This was initial discovered in this pull-request:
+	 * https://github.com/WordPress/gutenberg/pull/23425
+	 */
+	const initialAccessibleToolbarState = true;
+
 	// By default, it's gonna render NavigableMenu. If all the tabbable elements
 	// inside the toolbar are ToolbarItem components (or derived components like
 	// ToolbarButton), then we can wrap them with the accessible Toolbar
 	// component.
-	const [ isAccessibleToolbar, setIsAccessibleToolbar ] = useState( false );
+	const [ isAccessibleToolbar, setIsAccessibleToolbar ] = useState(
+		initialAccessibleToolbarState
+	);
 
 	const determineIsAccessibleToolbar = useCallback( () => {
 		const tabbables = focus.tabbable.find( ref.current );