Editor inline styles generated by block supports are broken in Query Loop block preview

[fabiankaegy]

Description

When using a Query Loop to display content, all but the currently selected items in the query get rendered using the __experimentalUseBlockPreview hook.

In WordPress 6.4 Beta 1 this block preview does not get any of the blocks generated inline styles from the style engine applied causing broken layouts in the editor.

The items rendered by the useBlockPreview hook are missing the generated classnames wp-container-278

Step-by-step reproduction instructions

1. Insert a Query Loop Block
2. Insert a "Stack" block within the Post Template
3. Set the layout of the Stack block to centered
4. Change the block gap value of the stack block
5. Select a different item in the query loop
6. you will see the layout being broken for the non selected items

Screenshots, screen recording, code snippet

CleanShot.2023-10-01.at.17.19.18.mp4

Environment info

• WordPress 6.4 Beta 1
• Twenty Twenty Four Theme
• No Gutenberg Plugin active

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

[tellthemachines]

Hmm this is an interesting one. The wp-container- class is being generated anew for the selected block on selection, because in the selected state it uses different markup from the unselected state which is static. Seems that the unselected state, though it still gets the wp-container- class, doesn't get any of the actual styles. Not quite sure why! Looking into it.

[tellthemachines]

Looks like this regression was introduced in #52888 and it's happening with any block supports requiring extra styles to be output; setting duotone on featured images has the same effect:

It's funny because setStyleOverride is running for all the blocks with wp-container- classes but the styleOverrides state just stops accepting new entries after a certain point 🤔

[andrewserong]

Hrm, this is possibly clutching at straws, but the previews use their own ExperimentalBlockEditorProvider, e.g. here:

gutenberg/packages/block-editor/src/components/block-preview/index.js

Lines 126 to 133 in 205f1e3

	const children = (
	<ExperimentalBlockEditorProvider
	value={ renderedBlocks }
	settings={ settings }
	>
	<BlockListItems renderAppender={ false } layout={ layout } />
	</ExperimentalBlockEditorProvider>
	);

They receive the value for settings from the wrapping BlockPreview or useBlockPreview code via calls to select( blockEditorStore ).getSettings() which means that values set in the "parent" will flow down to the preview... but does this mean that when things in the preview make calls to update things in the block editor state, they won't be propagated into the settings that get passed down to it? I guess what I mean is, is it possible that the preview versions of the blocks are correctly calling setStyleOverride, but the value never goes anywhere, because it's within one of these child ExperimtanlBlockEditorProviders? CC: @ellatrix

[ellatrix]

I'm not familiar at all with useBlockPreview. Looks like that's just being used for two components? Is it supposed to preview block but within another block list? I see this is not the iframed preview.

It's worth noting that the overrides are not saved in the settings, but rather separately in the block editor store. These overrides are then consumed by the EditorStyles component and override the style passed as editor settings.

Does ExperimentalBlockEditorProvider create a new block editor store or something? Maybe the overrides go to a different store and EditorStyles doesn't pick them up?

[andrewserong]

Is it supposed to preview block but within another block list? I see this is not the iframed preview.

Yes, it's used to ensure previewed block markup is rendered in situ, but is neither interactive, nor in a separate iframe preview. It looks like it's used by both the Post Template and the Comment Template blocks.

From a little digging it looks like ExperimentalBlockEditorProvider does use a sub registry, introduced way back in #14678 to effectively create a kind of local state. I'm a little bit out of my depth digging into the internals there, so I'll just ping @youknowriad, too...

Curiously, however, if I create a synced pattern that contains elements and Duotone styles, they're all rendered correctly in other instances of BlockPreview which uses the iframe, so the issue does appear to be isolated to useBlockPreview as far as I can tell 🤔. Could the iframe in BlockPreview be fixing things up in a way that doesn't happen for useBlockPreview?

Here's a quick screenshot of the BlockPreview for a pattern containing Duotone and Elements styles (just proves that BlockPreviews appear to be rendering styles correctly):