Site Editor: custom block editor javascript assets don't load in iframe context

[glendaviesnz]

Description

Where custom blocks rely on additional js script resources in the editor context, and where these scripts are dependant on being in the correct parent window context, the blocks fail to run correctly when added in the site editor context. This is because the scripts are loaded in the context of the main site editor window instead of in the editor iframe.

Step-by-step reproduction instructions

• Run up a local test env with Gutenberg plugin, an FSE compatible theme, and the Jetpack plugin
• Insert a Jetpack map block in a post and notice that the mapblock-gl.js is loaded and the map instantiates as expected
• Insert a Jetpack map block in the site editor and notice that although the mapblock-gl.js script is loaded the block fails to load with an Invalid type: container must be a String or HTMLElement error. This is because the mapblock-gl.js library is instantiated on the parent window but the map element lives in the editor iframe and in a number of places this library expects the map element to be in the parent window.

Expected behaviour

Scripts enqueued with enqueue_block_editor_assets are aware of the current editor context and load in the iframe window if the editor is iframed

Actual behaviour

enqueue_block_editor_assets always adds scripts to the parent window regardless of editor context.

While it would be useful to have enqueue_block_editor_assets aware of the iframe context, it may not be the best/only solution for all use cases. For instance the mapbox-gl.js file mentioned above is 760Kb and it doesn't make sense to load this with every editor load if there are no map blocks on the current page. To avoid this Jetpack currently lazy loads the js into the editor only when a map block is added to the editor. It doesn't appear that the existing webpack lazy import that is used to achieve this can be used to load the files into the iframe because as soon as it is imported it is bound to the parent window context, and we can't see a way to have this sort of import run in the editor iframe context.

There is a PoC implementation of a small library that can load an external library into the correct window context that works to get the mentioned map block running in the site editor. Maybe this is something worth exploring adding to core Gutenberg to give custom block developers a way to lazy load assets into the editor context?

[ramonjd]

While it would be useful to have enqueue_block_editor_assets aware of the iframe context, it may not be the best/only solution for all use cases.

I'm facing a situation whereby a block enqueues core assets, e.g., wp_enqueue_style( 'wp-mediaelement' );. I'm not sure how to approach it.

For example, the Jetpack podcast player, and any media player that relies on WordPress mediaelement assets, it'd be nifty to somehow make enqueue_block_editor_assets aware of the block's context, i.e., Am I in the block editor or site editor?, and enqueue assets accordingly in the correct parent window.

The media assets could be lazy-loaded as well of course, but there appears to be a more foundational expectation that a block's enqueued or runtime assets are available within the site editor iframe.

For now the temporary solution I've found is to find the <link /> elements I need in the parent window and move them into the site editor iframe. 😱

[Addison-Stavlo]

cc - @ellatrix @gziolo @youknowriad - it sounds like the Iframing editor content experiment in the site editor is posing some challenges for 3rd party blocks. Any ideas here?

[ellatrix]

Fixed in #31873. Let's close this issue and create follow-up issue if needed.

@Addison-Stavlo Sure, there will be other challenges. We'll need to create a dev note once beta is out to clarify.