Certain blocks like images break editor width

[kean]

Description

Certain blocks like images break editor width

ScreenRecording_02-11-2025.15-47-25_1.MP4

Step-by-step reproduction instructions

• Add an image block
• Specify the image width that's larger than the viewport

Screenshots, screen recording, code snippet

No response

Environment info

No response

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

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[kean]

I can't see these options – Aspect Ratio, Width, Height – from the mobile editor:

[dcalhoun]

Certain blocks like images break editor width

This is an interesting case, and gets into really weird territory. I'm not entirely confident in how the editor should behave in this case. One could argue the editor should constrain UI to fit the device dimensions, avoiding overflow; one could also argue the editor's explicit styling—the fixed image dimensions—should be respected.

What are your thoughts on this?

There appears to be a few open issues in Gutenberg that directly or indirectly relate to this subject:

• Image block: unwrap img element in editor WordPress/gutenberg#68666
• Image in row block shrinks on front end but not in the editor WordPress/gutenberg#68057
• Image changes sizes upon selection WordPress/gutenberg#67506
• Manual image size input disregarded after clicking an image WordPress/gutenberg#68814
• Image does not return to full width after mobile preview in the post editor WordPress/gutenberg#68751

[dcalhoun]

I can't see these options – Aspect Ratio, Width, Height – from the mobile editor:

This should likely be captured as a separate issue.

[kean]

What are your thoughts on this?

In this case, the images in the rendered post respect the viewport and don't cause the overflow in the browser, so it's pretty clear that the editor should also render them this way.

In general case, I'd say block should never cause the scroll overflow of the document. For example, if you add a large table, the table block/element should have scroll overflow. The current Table block also leaves a lot to be desired as it doesn't have scroll overflow and instead shrinks the table to fit the viewport.

For comparison, here's GBK vs Pages.

There may be exceptions.

It looks like a duplicate #78. I'm not sure how I missed it in a repo with 18 issues 😓

[kean]

This should likely be captured as a separate issue.

I opened a new issue: #93.