Site Editor: style variation preview visually jumps at certain browser height

[lukecarbis]

Description

When viewing the styles panel with just the right browser height (something close to 1000px for me – which incidentally is the full height on a 2023 MacBook Pro with the dock hidden), the previews jump and move around the screen constantly.

This seems to occur because the scroll bar on MacOS only shows when there's content to scroll. The Previews seem like the try to scale up to fit the available space. When they do, they cause the scroll bar to display, which reduces the available space. The previews then shrink again, causing the scroll bar to hide. This loops indefinitely.

Changing the System Setting > Appearance > Show scroll bars to "Always" prevents the problem from occurring.

Step-by-step reproduction instructions

1. On MacOS, set the System Setting > Appearance > Show scroll bars setting to "When scrolling"
2. Open your WordPress site in Safari
3. Navigate to Appearance > Editor > Styles
4. Resize your browser window to be around 1000px high – just on the edge of whether the scrollbar should display (I've found there's a range of around 20px or so where this bug is triggered)

Screenshots, screen recording, code snippet

Screen.Recording.2023-10-06.at.8.18.39.am.mov

Environment info

• WordPress 6.3.1
• With and without Gutenberg 16.7.0 enabled
• Safari 17.0
• Desktop with MacOS Sonoma
• Twenty Twenty-Three

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

[annezazu]

Tentatively adding to 6.4's board since it's occurring with 16.7 and could be present in the release. I can't replicate in Chrome nor in Safari on MacOS Ventura 13.6 using 6.3.1 and GB 16.7. I had system settings set to the following:

But couldn't replicate across any of the options. Going to add needs testing label for now as I can't replicate.

[ironprogrammer]

Thanks for the report, @lukecarbis! I was also able to reproduce this one.

Test Report

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 13.6
• Browser: Safari 16.6
• Server: nginx/1.25.2
• PHP: 7.4.33
• WordPress: 6.4-beta2-56769-src
• Theme: twentytwentythree v1.2
• Active Plugins:
  • gutenberg v16.8.0-rc.1
• macOS System Settings > Appearance > Show scroll bars set to "Automatically based on mouse or trackpad"

Actual Results

• ✅ When browser window is sized between ~1093 <> 1065, the Styles panel previews begin to shift around ("dance").

Additional Information

• Just noting here that I did not experience this bug on the right-hand side of the editor under global Styles > Browse styles sidebar.

Supplemental Artifacts

Figure 1: Demonstration of browser window height effect on Styles variations previews.

[andrewserong]

What a hilariously inconvenient bug! 😅

I didn't get a chance to look into a fix today, but I think I've found the cause:

In the sidebar we currently use scrollbar-gutter: stable which reserves space to the right edge of the secondary sidebar, that is, the space where a scrollbar would usually appear. This prevents the UI from jumping when a scrollbar becomes present:

gutenberg/packages/edit-site/src/components/sidebar/style.scss

Line 7 in a1d941e

scrollbar-gutter: stable;

The trouble is, that CSS property is not available in Safari: https://caniuse.com/mdn-css_properties_scrollbar-gutter so on Safari when a scrollbar appears, the width of the content area of the sidebar will be reduced. Then, over in the preview for each of these styles, there's a useResizeObserver that checks how wide the current container is, and then determines the ratio to use for the preview based on that width:

gutenberg/packages/edit-site/src/components/global-styles/preview.js

Line 81 in 550ca6e

const [ containerResizeListener, { width } ] = useResizeObserver();

Then, that ratio is applied to the preview, affecting how tall each of those previews are. I think the endless cycle (or dancing effect) is a result of the following, though I'm not 100% sure which event occurs first:

1. The sidebar is rendered without any previews
2. Enough previews are rendered to cause a scrollbar to appear
3. The presence of the scrollbar causes the sizes of the previews to be recalculated
4. The previews are re-rendered, and now that they're smaller, result in no scrollbar being present
5. As no scrollbar is present, the container is now wider, so the previews can be rendered larger again
6. The previews are rendered larger, which introduces the scrollbar (we are now back at step 2, so the rest is an infinite loop)

So, for anyone looking into this issue, to reproduce, you'll need to:

• Use Safari browser
• A browser window that's the perfect height for the above loop to occur

I'm not too sure what the ideal fix would be here — I suspect either somewhere in preview.js, or we might do with a max-width on the container for the previews that factors in the possibility of a sidebar.

If no-one beats me to it, I can look into potential fixes tomorrow!

[lukecarbis]

Thank you @andrewserong!

[andrewserong]

Pleasure, thank you for reporting it @lukecarbis! 🎉