Slideshow block: On FSE Templates, improperly responsive images are loading intermittently

[jp-imagines]

Update 2023-03-23 from cuemarie - this one took me a few tries to replicate, so please see my triage round two comment below. My steps to replicate:

1. On a simple site with an FSE theme active, add the Slideshow block to a template, with several images from Pexel free image library.
2. Save and view the site
3. Inspect the slideshow, and check out how the <figure> element pulls the image.
4. Return to the editor and remove a caption from one of the images
5. Save and view the site again
6. Now you should see a different response from the images. If you inspect the slideshow > <figure> element again, there's new responsiveness going on with the images.

Quick summary

Adding the Slideshow block to a template can lead to some issues with image sizes – in particular, the images can appear much smaller than expected on the live site. In my tests, this behavior was consistent on mobile, but sometimes was "delayed" on larger screens – the images sometimes loaded at the expected size and then quickly snapped to a smaller size. (In most cases, the images always displayed at the smaller size.)

Steps to reproduce

1. Start with a site with a block/FSE theme active.
2. Open the Site Editor.
3. Add a Slideshow block with a few images to the template, e.g. inside the header or below the header template part. Test adding it to a Group block as well.
4. View the live site.

What you expected to happen

The slideshow should appear on the live site as it does in the editor, with images sized to fit the slideshow area.

What actually happened

The images are very small:

Impact

Some (< 50%)

Available workarounds?

No but the platform is still usable

Platform (Simple and/or Atomic)

Simple

Logs or notes

Only tested on Simple so far, unsure if this also affects other platforms. Replicated on Chrome and Firefox (latest versions), as well as Chrome on Android.

From the browser console, it looks like the images are being loaded in with ?w= URL parameters to specifically shrink them to a smaller-than-expected size, so using CSS to resize them isn't possible.

Setting the block to wide or full width (if inside a Group block) fixes the issue, but the slideshow may then be larger than desired.

[jp-imagines]

Initially reported in 6300144-zd-woothemes.

[github-actions[bot]]

Support References

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

• [ ] 6300144-zen
• [ ] 7447913-zen

[cuemarie]

Triage Round One

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

• Tested on Simple – Could Not Replicate
• Tested on Atomic –Could Not Replicate

📌 FINDINGS/SCREENSHOTS/VIDEO

• So far I'm unable to replicate this in test environments. I've added a Slideshow block with 4 large landscape orientation images to the Front page template of Blank Canvas on both Simple and Atomic. On the live site, the slideshow displays as expected, using both desktop and mobile browsers.

Screenshots/Recordings

Mobile Response https://github.com/Automattic/wp-calypso/assets/27249804/3c511606-d48e-4dd1-8d64-c94185e13665

Desktop Response (With responsive controls tests) https://github.com/Automattic/wp-calypso/assets/27249804/2bda70ae-e355-4be6-aad7-533ea0bc50ca

📌 ACTIONS

• Requested author feedback

📌 Message to Author

• Hey @jp-imagines ! Anything that I'm missing in these replication steps? You mention adding the slideshow to the header or just the template itself, so it seems that isn't a specific cause, and then you also mentioned an additional unexpected change when wrapping the block in a Group, but from my understanding of this report, it seems the issue you're reporting is specifically just the Slideshow block's behavior on a template versus a page.
• Let me know if there's something more specific I can do to replicate in a test environment! And to clarify, were you able to replicate this issue outside the user's site? Thanks!

[jp-imagines]

@cuemarie I was able to replicate on a test site, though I'm getting really inconsistent results now: https://premium.wootestjpi.blog/

I currently have the Slideshow (align center) in a Group block, as that's similar to what the user I had been chatting with had set up. (It also makes it a bit more obvious that the images are shrunk, when they do shrink.)

Right now, it seems to load properly at first, and then they shrink after reloading the page. Mobile is always affected on my end.

That said, the user I spoke with seems to have made some changes to the images they're using, and suddenly I can't replicate on their site anymore. Not sure why. 🤔

(Just in case: my test site is on Archeo. User's site is on Masu.)

[cuemarie]

Triage Round Two

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

• Tested on Simple – Replicated

📌 FINDINGS/SCREENSHOTS/VIDEO

• @jp-imagines Thanks so much for those additional notes! That helped me make some headway 👍
• I was able to replicate this across 2 Simple sites, one with Blank Canvas and the other with Twenty Twenty Three.
• When I first create a slideshow, it appears as expected, even after several refreshes. Inspecting the image shows the <figure> element is loading a direct src image URL.
• Next, if I remove the caption for any of the images and save, now responsive images are loading instead, using srcset and src-orig, and scaling the image. Even if I go back in and add a caption back, the scaling remains, causing intermittent differences in how the images load.

Screenshots/Recordings

https://github.com/Automattic/wp-calypso/assets/27249804/7b195dea-847d-4bde-8f34-64f4500a0623

Here you can see a side-by-side of the same site, before and right after I removed the caption of the first image:

I waited a few minutes and refreshed again, and the image does now appear larger again, but not the same size as it was originally, and the different

Before editing caption, inspecting the <figure> shows:

<img class="wp-block-jetpack-slideshow_image wp-image-617" decoding="async" alt="" data-id="617" src="https://mqtest262591086.files.wordpress.com/2023/05/pexels-photo-2400030.jpeg" scale="0" width="1880" height="1217">

After editing the caption, inspecting the <figure> reveals more going on:

<img class="wp-block-jetpack-slideshow_image wp-image-617" decoding="async" alt="" data-id="617" src="https://mqtest262591086.files.wordpress.com/2023/05/pexels-photo-2400030.jpeg"?w=866" srcset="https://mqtest262591086.files.wordpress.com/2023/05/pexels-photo-2400030.jpeg?w=866&zoom=2 2x" src-orig="https://mqtest262591086.files.wordpress.com/2023/05/pexels-photo-2400030.jpeg?w=1024" scale="2" width="866" height="560">

📌 ACTIONS

• Assigned to Other
• CC: @jeherve for Jetpack's Slideshow block

[jeherve]

Transferring to the Jetpack repo, where the Slideshow block lives.

[jeherve]

related: #22834

[github-actions[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive for the past 6 months.
• It hasn’t been labeled `[Pri] BLOCKER`, `[Pri] High`, `[Type] Feature Request`, `[Type] Enhancement`, `[Type] Janitorial`, `Good For Community`, `[Type] Good First Bug`, etc.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[OmarFPG]

Another occurrence: 7447913-zen

[monsieur-z]

I've spent some time troubleshooting this issue, and though I haven't been able to reproduce it myself, I've got an idea of what's happening.

This function in the Slideshow block determines what image URL to use: the URL depends on the size setting, which is set to Large by default.

If the size setting is not defined or if the Large version of the image doesn't exist, the block falls back to using the Full Size version.

When one adds an image using an external source (tested with Pexel), resized versions of the selected image are not processed—or available. However, after updating the gallery (such as deleting a caption in the above description), these versions are available.

On initial selection	After updating the gallery

So, when an image is added to the slideshow, no resized version exists, and the block falls back to the full-size version. After the gallery is updated, resized versions are available, and the one that matches the size setting is used. That explains the w query parameter in the image URL.

What I still don't understand is why the image gets so small. The size attribute is set to Large by default and doesn't seem to be updated to another value anywhere in the code (e.g., the value is the same on mobile and desktop). Could users have set it manually to Small, for instance?

A proper fix would likely involve ensuring resized versions of the image are available from the get-go. As far as I understand, that should be handled in WordPress core.

[monsieur-z]

A proper fix would likely involve ensuring resized versions of the image are available from the get-go. As far as I understand, that should be handled in WordPress core.

Not sure what team can comment on that. Do you maybe have some input, @inaikem?

[inaikem]

Good question and thanks for the ping! I'm not entirely sure either but I think @jordesign and @annezazu might be able to help on the Dotorg side.

[monsieur-z]

Re-pinging you for visibility, @jordesign and @annezazu. To sum up the issue: after an image is uploaded to the gallery, its resized versions are either not processed or unavailable. But once you update the gallery, they are. That doesn't seem Jetpack-related. Any idea who's better positioned to investigate that?

[annezazu]

I've flagged this up to some folks to see if we can get more insight around the root problem.

[azaozz]

It's true that processing an image after uploading takes some time. In some cases that may be quite a bit, 20-30 seconds or more. So assuming there may be fallback somewhere to use/show the originally uploaded image while the sub-sizes are being created. That would explain why the sub-sizes are available later after updating the gallery.

That doesn't seem Jetpack-related

Looked at how that works in the (standard) Gallery block: after an image is uploaded it shows a spinner and waits for the sub-sizes, then inserts the proper sized image. Unsure if that's handled in the same way in the Slideshow?

[monsieur-z]

It seems that the Gallery block doesn't have that issue, indeed. We'll look at its implementation to see what we can take away from it. Thanks for pointing this out @azaozz.