Tiled Gallery: images collapse to ~105px in the editor when the canvas is not iframed (16.0 regression from #50016)

[davemac]

Impacted plugin

Jetpack

Quick summary

Since Jetpack 16.0, Tiled Gallery blocks render with tiny images (roughly 105px wide) in the block editor whenever the editor canvas is not iframed (for example a classic theme with blocks registered at apiVersion 2, which keeps WordPress on the non-iframed canvas). The published page is unaffected.

The regression comes from #50016, which added getFlexContainer() to extensions/blocks/tiled-gallery/layout/mosaic/index.js. The ancestor walk has no boundary at the block canvas, so in a non-iframed editor it escapes the post content entirely and matches a display: flex element in the editor chrome. getLayoutWidth() then divides that chrome element's width by its child count and lays the mosaic out against the result.

Steps to reproduce

1. Run a classic (non-block) theme that registers at least one block at apiVersion 2, so the post editor canvas is not iframed. An ACF block is an easy way to get this.
2. Activate Jetpack 16.0 and edit a post containing a Tiled Gallery block.
3. Trigger a layout pass (this happens on load once images resolve, or on any window resize or sidebar toggle).

Every .tiled-gallery__item receives inline styles in the order of height:69.39px; width:105.58px; and the gallery collapses. Converting the block to a core Gallery restores normal sizing, which is how our editorial team first isolated it.

On Jetpack 15.9 the same post renders correctly. The front end is fine on both versions because the view script recalculates against the real container.

Diagnosis

On our production site (WordPress 7.0.1, Chrome, classic theme with ACF blocks):

• getFlexContainer() walks up from the gallery and returns a classless emotion-styled div inside .interface-interface-skeleton__body, whose children are the popover slot, the block canvas cover and seventeen <style> elements: 19 children in total.
• getLayoutWidth() computes (2006px - gaps) / 19 = 105.58px.
• handleRowResize() then writes that width into every item via applyImgRatio().

Two contributing problems:

1. The ancestor walk should stop at the block canvas root (.editor-styles-wrapper / .is-root-container), or only honour flex ancestors that are themselves blocks (for example [data-block] or .wp-block). Editor chrome should never be a layout target.
2. container.children.length counts all element children, including <style> tags and absolutely positioned slots that are not meaningful flex items, so the equal-share division is wrong even when a legitimate flex container is found.

There is also a persistence angle: for a newly created or re-edited gallery, onResize saves the miscalculated columnWidths percentages into the block attributes (the changed guard in edit.js only protects untouched galleries).

Workaround

Editor-side CSS neutralises the broken inline sizes while keeping the saved column proportions:

.wp-block-jetpack-tiled-gallery .tiled-gallery__item {
	width: auto !important;
	height: auto !important;
}

A screenshot or video displaying the issue

An 827px-wide gallery item after one layout pass, taken from the React component instance on the live editor:

itemStyles: "height:69.3859649122807px;width:105.57894736842105px;"
getLayoutWidth(): 105.57894736842105

Site owner impact

Fewer than 20% of the total users, but every site whose editor is not iframed is affected

Severity

Moderate

What other plugins are installed on your site?

Advanced Custom Fields Pro (relevant: its blocks keep the editor canvas non-iframed), Gravity Forms, SEOPress. Deactivating them does not change the behaviour as long as the canvas stays non-iframed.

Platform

Self-hosted