Image block: images stretched on smaller devices unless a scale behaviour is set. If the selection is Contain, large margins are added.

[filipanoscampos]

Quick summary

Recently, the Image Block received a much-welcomed scaling setting.
Yet, there appear to be some unexpected results.

If the image is resized and the user does not choose a scaling behavior, the image is stretched on mobile devices.
If the user chooses the option to contain the image size, there are large white margins added above and below the image on small devices.

Steps to reproduce

1. Add an image block to a page or post, preferably win-between two Paragraph blocks
2. Resize the image
3. Save your changes and visit the post from a small device (less than 780px). Notice the stretched image.
   

4. Now, set the image to Contain and save your changes. Notice the large margins when the post is visited from a small device.
   

What you expected to happen

The image to adjust to the smaller width, without stretching or extra margins.

What actually happened

The image is stretched or, if we set it to contain, there is a large white margin above and below the image.

Impact

Most (> 50%)

Available workarounds?

Yes, difficult to implement

Platform (Simple and/or Atomic)

Simple and Atomic

Logs or notes

Available workarounds:

• Using the Classic Block to add an image
• Some CSS that @Robertght kindly shared:

@media screen and (max-width: 768px){
 .wp-block-image img {
    height: auto !important;
 }
}

First reportedon this interaction 6549118-zd-woothemes
Related conversation, here: p1689669069885049-slack-C03TY6J1A

Update - see easier workaround in comments

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 6549118-zen
• 6547432-zen
• 6589094-zen
• 6604157-zen
• 6641104-zen
• 6642481-zen
• 6640399-zen
• 6689829-zen
• 6799728-zen
• 7138606-zen
• 7139337-zen

[cuemarie]

📌 SCRUBBING : RESULT - Replicated / Could Not Replicate / Uncertain

• Tested on Simple – Replicated
• Tested on Atomic – Replicated
• Replicable outside of Dotcom – Yes

📌 FINDINGS/SCREENSHOTS/VIDEO

• Replicated as described across WordPress.com and WordPress.org test sites.

Screenshots/Recordings

d3qSap.mov

Replicated in Gutenberg 16.2.1, 16.2.0, 16.1.2, and with Gutenberg deactivated.

📌 ACTIONS

• Assigned to Other
• Added to ‘HE Cross-repo Watchlist’ project board

[cuemarie]

Reported here: WordPress/gutenberg#52739

[cuemarie]

Workaround

In the editor, clear out the Height selection and it will default to Auto and remove the scaling feature. This will correct the issue:

Editor

Live Site

[Robertght]

It's likely the change is caused by this: p7DVsv-hV9-p2

@sgomes can you confirm this is the same case? In this case, until stage 3, the users cannot wait for images to be stretched on mobile.

[sgomes]

Hey @Robertght 👋

I can't seem to reproduce the issue, I'm afraid 😕 Does this require a particular theme?

Without any further information, I doubt that the issue is related to the rollout in p7DVsv-hV9-p2, since that is not affecting any user blogs at the moment, but I'd like to make sure.

[sgomes]

Thank you to @filipanoscampos for a test case 👍

This seems to be unrelated to the rollout in p7DVsv-hV9-p2, as I expected. It looks like an issue with how this feature is implemented in Gutenberg.

The element has the following styles:

{
    width: 545px;
    height: 472px;
}

But Gutenberg also adds the following:

.wp-block-image img {
    box-sizing: border-box;
    height: auto;
    max-width: 100%;
    vertical-align: bottom;
}

This means that when max-width kicks in, the height is no longer proportional, because it’s using the 472px fixed value, which has precedence over the auto because it’s in an element style attribute.

[kelasante]

Another report in 6547432-zen

[Robertght]

Another in #6589094-zen

[jp-imagines]

Another report in 6604157-zd-woothemes, though I wasn't able to replicate in Firefox on Android.

This user was reportedly able to resolve things by changing the "Scale" setting from Cover to Contain and choosing a different aspect ratio.

[cuemarie]

Looks like a fix for this will be incoming with Gutenberg 16.5 in WordPress/gutenberg#53274

[wpshellbelle]

6641104-zd

[ClassicRKR27]

6642481-zd-a8c

[wpshellbelle]

6640399-zd

[Robertght]

6689829-zen

[jp-imagines]

Reported in 6799728-zd-a8c

[Aurorum]

Further reports here - do we know when the fix is to be rolled out or if it'll be retrospective to affected blocks?

• 7138606-zen
• 7139337-zen

[cuemarie]

@Aurorum Thanks for that ask!

I just retested on a new Free Site in WordPress.com, and the issue is no longer present, so the fix has landed for new sites.

Screen.Capture.on.2023-10-09.at.13-38-30.mov

---

As for whether it's expected to retroactively apply to blocks, I'm not sure. I'll do some digging today to see what I can find out.

[cuemarie]

@Aurorum Follow up - it looks like the fix applies to new image blocks, but existing image blocks that were created while this issue was in effect will need to be corrected. That's because when the image was created and resized, a height was applied to the image in the editor - upgrading Gutenberg past 16.5 (where the fix landed) does not make changes to those blocks.

You can see an example of this test on a self-hosted site below, along with the manual correction needed:

RzH20U.mp4

TL;DR

The bug is fixed, but users will need to edit their image blocks and remove the height setting, which will clear that height and set it back to Auto. Once this is done, the CSS workaround is no longer needed.

📌 ACTIONS

• Closed as resolved (by: Image block: Fix stretched images constrained by max-width WordPress/gutenberg#53274 )

[Aurorum]

Thanks @cuemarie - much appreciated.