Block editor: Hotfix performance regression

[mmtr]

Fixes Automattic/wp-calypso#98377
See p1737631296756739-slack-C02FMH4G8

Proposed changes:

Overrides the wp-block-editor script with a custom version that includes these changes (props to @youknowriad):

diff --git a/packages/block-editor/src/store/selectors.js b/packages/block-editor/src/store/selectors.js
index 22d725bbcd6..fed2331edc6 100644
--- a/packages/block-editor/src/store/selectors.js
+++ b/packages/block-editor/src/store/selectors.js
@@ -1626,15 +1626,22 @@ const isBlockVisibleInTheInserter = (
 		Array.isArray( blockType.parent ) ? blockType.parent : []
 	).concat( Array.isArray( blockType.ancestor ) ? blockType.ancestor : [] );
 	if ( parents.length > 0 ) {
-		const rootBlockName = getBlockName( state, rootClientId );
 		// This is an exception to the rule that says that all blocks are visible in the inserter.
 		// Blocks that require a given parent or ancestor are only visible if we're within that parent.
-		return (
-			parents.includes( 'core/post-content' ) ||
-			parents.includes( rootBlockName ) ||
-			getBlockParentsByBlockName( state, rootClientId, parents ).length >
-				0
-		);
+		if ( parents.includes( 'core/post-content' ) ) {
+			return true;
+		}
+		let current = rootClientId;
+		let hasParent = false;
+		do {
+			const currentName = getBlockName( state, current );
+			if ( parents.includes( currentName ) ) {
+				hasParent = true;
+				break;
+			}
+			current = state.blocks.parents.get( current );
+		} while ( current );
+		return hasParent;
 	}
 
 	return true;

This way, we can prevent a performance degradation that started with WordPress/gutenberg#67734 which is currently present in Gutenberg v19.9.0, v20.0.0, and v20.1.0, and particularly on plugins that register blocks like Jetpack or WooCommerce.

This is especially relevant for Dotcom sites since the Gutenberg version has been pinned to v20.0.0 and there are no plans currently to update it (p58i-jaO-p2).

The custom wp-block-editor script has been built for each of the affected Gutenberg versions.

Before

Screen.Recording.2025-01-24.at.17.37.57.mov

After

Screen.Recording.2025-01-24.at.18.19.47.mov

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

N/A

Does this pull request change what data or activity we track or use?

No

Testing instructions:

• Apply these changes to an Atomic site
• Install WooCommerce and activate it
• Open the site editor
• Edit the navigation block and add some submenu items
• Save the changes and reload
• When hovering a menu, make sure the submenu appears immediately
• When selecting a menu from the list view, make sure the menu is selected immediately
• Test with different Gutenberg versions and with Gutenberg inactive, and make sure everything works as expected

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the hotfix/block-editor-performance branch.

  • For jetpack-mu-wpcom changes, also add define( 'JETPACK_MU_WPCOM_LOAD_VIA_BETA_PLUGIN', true ); to your wp-config.php file.

• To test on Simple, run the following command on your sandbox:

  bin/jetpack-downloader test jetpack-mu-wpcom-plugin hotfix/block-editor-performance
  

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Choose a review path based on your changes:
   • A. Team Review: add the "[Status] Needs Team Review" label
     • For most changes, including minor cross-team impacts.
     • Example: Updating a team-specific component or a small change to a shared library.
   • B. Crew Review: add the "[Status] Needs Review" label
     • For significant changes to core functionality.
     • Example: Major updates to a shared library or complex features.
   • C. Both: Start with Team, then request Crew
     • For complex changes or when you need extra confidence.
     • Example: Refactor affecting multiple systems.
3. Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

[jeherve]

This tests well for me. I would have a couple of last remarks, but no blockers:

• What would you think about making the function name, jetpack_hotfix_block_editor_script, a bit more specific about the versions / the problem it targets, so we know what this was about in a few years. Maybe the docblock could include more information?
• Maybe that docblock could mention how the min. files were created? Or maybe just point to this PR for more information?
• The file is currently loaded even if Jetpack is not connected to WordPress.com yet, or if Jetpack's own block bundle is not loaded because the feature has been disabled. I think that's fine, the hotfix would benefit everyone anyway, but I wanted to make sure that was intentional.
• In #41333 we ship the hotfix only in mu-wpcom. If the performance impact touches everyone, regardless of the platform, I think it makes sense to ship it in Jetpack for now, but maybe there should be a clearer way for folks reviewing changes like this to understand why a hotfix goes in one plugin vs. the other.

[youknowriad]

Looks like a fix for this is coming upstream, I wonder if it's worth keeping.

[mmtr]

Looks like a fix for this is coming upstream, I wonder if it's worth keeping.

We pinned Gutenberg v20 in Dotcom, so unless we revert that decision, I think we're going to need this hotfix. See p9oQ9f-2Bq-p2#comment-3374

[mmtr]

What would you think about making the function name, jetpack_hotfix_block_editor_script, a bit more specific about the versions / the problem it targets, so we know what this was about in a few years. Maybe the docblock could include more information?
Maybe that docblock could mention how the min. files were created? Or maybe just point to this PR for more information?

Good callout. Renamed the function and updated the docblock in b02606a

The file is currently loaded even if Jetpack is not connected to WordPress.com yet, or if Jetpack's own block bundle is not loaded because the feature has been disabled. I think that's fine, the hotfix would benefit everyone anyway, but I wanted to make sure that was intentional.

Definitely, not intentional. Although the issue is indeed affecting everyone, is almost unnoticeable if the site doesn't have a plugin registering additional blocks. Since Jetpack is one of these plugins, I think it'd be better to target this hotfix to only when the Jetpack blocks are available.

In e22639a, I included an additional check for that.

In #41333 we ship the hotfix only in mu-wpcom. If the performance impact touches everyone, regardless of the platform, I think it makes sense to ship it in Jetpack for now, but maybe there should be a clearer way for folks reviewing changes like this to understand why a hotfix goes in one plugin vs. the other.

Yup, I'm aware of this inconsistency. I don't know why #41333 only hotfixed Dotcom sites, maybe the issue was specific to Dotcom sites. If that's not the case, I think we should apply to Jetpack sites too (cc @fushar). I briefly mentioned this too in p9oQ9f-2Bq-p2#comment-3374, since we're going to need more alignment with other folks (e.g. WooCommerce).

[fushar]

I don't know why #41333 only hotfixed Dotcom sites, maybe the issue was specific to Dotcom sites. If that's not the case, I think we should apply to Jetpack sites too (cc @fushar).

My understanding is that we need to hotfix to Dotcom (only) because the GB version is pinned there. Other hosts are free to upgrade the GB plugin whenever a fix is available upstream. Am I missing something?

[mmtr]

My understanding is that we need to hotfix to Dotcom (only) because the GB version is pinned there. Other hosts are free to upgrade the GB plugin whenever a fix is available upstream. Am I missing something?

That makes sense, yeah. Self-hosted sites are also more unlikely to have the Gutenberg plugin active. I guess I lost perspective because I started to work on this before the issue was fixed upstream, so I was considering a worst-case scenario where the issue was solved in the short term.

I'll move the changes here to jetpack-mu-wpcom.

[anomiex]

I'll move the changes here to jetpack-mu-wpcom.

Glad I looked at the comments before suggesting exactly that! 👍 😀

Even better would be to bump Gutenberg to a fixed version before freezing it, but 🤷.

[anomiex]

Looks reasonable to me, assuming we won't update Gutenberg directly to v20.2.0 on wpcom.

Haven't tested it myself though.

[dsas]

Tests fine on atomic for me, I can't repro the original issue with child blocks either. I can't repro the slowness on simple.

Perhaps we should commit the original source file here as well as the minified ones but given the hotfix is already merged upstream I guess it's unlikely to be useful.

[youknowriad]

I've been thinking about this change and I'm a bit concerned about it. the main issue is that people are going to use Jetpack with future Gutenberg versions that might introduce new functions and APIs to the block-editor package. When that happens, Jetpack will replace block-editor with an old patched version which means potential breakage. So unless we keep patching this package with every Gutenberg release, it's going to be very hard to keep this fix in place.

Given that the fix landed in Gutenberg upstream, I think we should just revert this PR.

[anomiex]

the main issue is that people are going to use Jetpack with future Gutenberg versions

In the end, the fix isn't in Jetpack at all. It's in the mu-wpcom package that's only intended for use in Simple and Atomic.

When that happens, Jetpack will replace block-editor with an old patched version which means potential breakage.

I note the fix here checks for specific Gutenberg versions. Later versions won't be replaced.

jetpack/projects/packages/jetpack-mu-wpcom/src/features/wpcom-hotfixes/wpcom-hotfixes.php

Lines 69 to 71 in ba9862b

	if ( ! in_array( GUTENBERG_VERSION, array( '19.9.0', '20.0.0', '20.1.0' ), true ) ) {
	return;
	}

[youknowriad]

I note the fix here checks for specific Gutenberg versions. Later versions won't be replaced.

I had missed that, that eases my concerns a bit. Thank you.