Site Editor: Browse styles expand indefinitely when a cover block is in template

[annezazu]

Description

If you add a cover block to a template in the Site Editor and open Styles > Browse Styles, the canvas will start to expand indefinitely.

Step-by-step reproduction instructions

1. Open Appearance > Editor
2. Open any template and add a cover block.
3. Open Styles and select "browse styles".
4. Notice that the canvas starts to expand indefinitely.
5. Remove cover block.
6. Open Styles and select "browse styles".
7. Notice problem goes away.

Screenshots, screen recording, code snippet

Screen.Recording.2023-12-27.at.12.51.51.PM.mov

Environment info

• WP 6.4.2
• GB 17.2.3 & GB 17.3

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

[t-hamano]

Similar issues have been reported several times in the past. We need to find a fundamental solution to this problem.

• Styles > Browse Styles: query loop causing ever expanding view when zoomed out #52297
• Site Editor: Endless scrolling in zoom out and style views when there are blocks with vh units #49299
• When changing style variations in the right sidebar, the preview changes abnormally vertically #52092
• BlockPreview: Patterns with VH units scale oddly  #50449
• Site Editor: Browse styles animation is too slow #49120

[annezazu]

Thanks for diving into the prior related issues :D Was going to do that today since I know I've opened a few already.

[ramonjd]

In WordPress 2023 theme it's noticeable on the home template with posts that have featured images.

I hinted at it over in #52297 (comment) - if it's the CSS transition delay that's causing the race condition between height calculation and animation, I'd be open to ditching these transitions completely. E.g.,

diff --git a/packages/block-editor/src/components/iframe/index.js b/packages/block-editor/src/components/iframe/index.js
index 1939f75811..ddada79746 100644
--- a/packages/block-editor/src/components/iframe/index.js
+++ b/packages/block-editor/src/components/iframe/index.js
@@ -264,7 +264,8 @@ function Iframe( {
 						scale !== 1
 							? `scale( ${ scale } )`
 							: props.style?.transform,
-					transition: 'all .3s',
+					//transition: 'all .3s',
+					transition: 'none',
 				} }
 				ref={ useMergeRefs( [ ref, setRef ] ) }
 				tabIndex={ tabIndex }

[annezazu]

Ran into this again and 😭 -ed. This would be such a nice quality of life to have fixed.

[ramonjd]

I've tried to find a way to mitigate this again. Here's a brain dump of what I'm seeing.

The issue can be recreated by inserting some containing blocks with vh values set. I'm using the 2023 theme.

To test, I'm previewing the editor via "Browsing styles" in the site editor, which triggers the resizeObserver. Here's some test HTML:

<!-- wp:group {"style":{"dimensions":{"minHeight":"100vh"}},"layout":{"type":"constrained"}} -->
<!-- wp:group {"style":{"dimensions":{"minHeight":"30.8vh"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group" style="min-height:30.8vh"><!-- wp:image {"id":37,"sizeSlug":"full","linkDestination":"none"} -->
<figure class="wp-block-image size-full"><img src="http://localhost:8888/wp-content/uploads/2024/01/white-bellied-swallow.jpg" alt="" class="wp-image-37"/></figure>
<!-- /wp:image --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

From what I can see, the Iframe's useResizeObserver is trying to calculate the height of the window as it's growing.

Element "A", with a vh minHeight value of 30vh for example, will take up 30% of the viewport height. As the window height grows, Element "A" also grows because it wants to get to that 30%.

The transition of all .3s makes it really obvious as it will stretch a little more slowly 😄

The only way I could stop this was to restrict the zoomed out editor's height based on the iframe's surrounding container height.

• Block editor canvas iframe: play around with restricting max height of iframe #58484

I also turned off the transition because it's not helpful.

I'm not sure this is the right way though — it's a hack — just posting this in case other folks have ideas.

[t-hamano]

I believe this issue has been fixed in #59334, but if you can reproduce this issue on trunk, feel free to reopen it at any time.