Unsupported block rendering can overflow the editor viewport causing unexpected horizontal scrolling

[dcalhoun]

Description

The web editor allows easily insetting a new, empty Paragraph block when clicking after the last block in the block canvas, if the last block is not a Paragraph block. That is currently unsupported in GutenbergKit.
When the post content includes an unsupported block, the block's contents can result in overflowing editor content, which creates a poor experience with horizontal scrolling.

Step-by-step reproduction instructions

Open a post that includes a Tiled Gallery block in the editor.

Expected behaviour

The editor displays an unsupported block warning and a reasonable rendering of the unsupported content.

Actual behaviour

The editor displays an unsupported block warning, but the unsupported content causes the editor content to overflow and allows for horizontal scrolling.

Screenshots or screen recording (optional)

rpreplay_final1738941318.mp4

WordPress information

• WordPress version:
• Gutenberg version:
• Are all plugins except Gutenberg deactivated?
• Are you using a default theme (e.g. Twenty Twenty-One)?

Device information

• Device: iPhone SE
• Operating system: iOS 18.2
• WordPress app version: 25.7.1

[dcalhoun]

Similar to #90 (comment), I'm not confident as to how a mobile editor should manage this situation. When recreating this scenario in the web editor, it renders this situation in the same manner—where the unsupported block content causes overflowing that results in horizontal editor scrolling.

Do we mimic the web editor's WYSIWYG—the overflow is literally what the front-end of the website renders—or we apply an opinionated constraint in the name of an improved mobile editing experience?

[twstokes]

where the unsupported block content causes overflowing that results in horizontal editor scrolling.

Interesting – unless I'm looking at something wrong, that didn't appear to be the case for me. On the web editor (desktop sized or mobile), the block appeared constrained by the width of the screen so the gallery images would dynamically resize down.

My expectation in the mobile editor is that I get a WYSIWYG (as close as possible) to the rendered mobile layout.

[dcalhoun]

@twstokes your screenshot showcases a supported Tiled Gallery block. The subject of this issue is that unsupported blocks can result in overflowing editor content.

I.e., if you disabled the Jetpack plugin for your test site, how does the editor then render the unsupported block content in both the editor and the front-end of the site? Does it differ in a narrow or wide viewport?

From my findings testing a jurassic.ninja site, unsupported block content can result in editor overflow in the web editor on any viewport size, it is merely dependent on the width of the content itself (e.g., image width). That editor result matches that rendering on the site's front-end—WYSIWYG. Thus, I posed the question: Should we adhere to WYWISYG (allow overflow) or enforce constraints to make the mobile editing experience more delightful (albeit less "accurate")?

[dcalhoun]

After considering this and #90, I opted to apply a reasonable constraint in #96 to ensure overflow scrolling does not disrupt the editing experience on a smaller devices.

[twstokes]

Thus, I posed the question: Should we adhere to WYWISYG (allow overflow) or enforce constraints to make the mobile editing experience more delightful (albeit less "accurate")?

Got it. I'd personally lean towards enforcing constraints / guardrails rather than staying true to broken content as it compromises the editing experience.

@twstokes your screenshot showcases a supported Tiled Gallery block. The subject of this issue is that unsupported blocks can result in overflowing editor content.

In my experience the block was unsupported in GutenbergKit, but rendered properly in the web editors and when published. This is a WPCOM Simple Site so I can't disable the Jetpack plugin. (I'll be glad to add you to it if needed)

So for me that was a separate, distinct problem: Creating a new page using this Portfolio theme in the app rendered broken content in the editor.

[dcalhoun]

Got it. I'd personally lean towards enforcing constraints / guardrails rather than staying true to broken content as it compromises the editing experience.

Makes sense. #96 aligns with this perspective.

So for me that was a separate, distinct problem: Creating a new page using this Portfolio theme in the app rendered broken content in the editor.

Fair, this relates to "a mobile-specific starter page template includes an unsupported block" referenced in the internal discussion (see: pbArwn-74j-p2#comment-8330). That problem also presents itself in Gutenberg Mobile, just in a different manner, where the fallback block is displayed.

Fallback block screenshot

I had not prioritized addressing that specific problem because I thought it was an internal- or dev-only issue. However, I was able to observe the problematic start page template in a production build just now. Strangely, the problematic template only shows up for some of my devices. I need to investigate that issue separately.