Automattic / jetpack

Security, performance, marketing, and design tools — Jetpack is made by WordPress experts to make WP sites safer and faster, and help you grow your traffic.
https://jetpack.com/
Other
1.59k stars 799 forks source link

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

Open jp-imagines opened 1 year ago

jp-imagines commented 1 year ago

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.

LYQ0Dy.png

What actually happened

The images are very small:

vWt6eR.png

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 commented 1 year ago

Initially reported in 6300144-zd-woothemes.

github-actions[bot] commented 1 year ago

Support References

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

cuemarie commented 1 year ago

Triage Round One

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

📌 FINDINGS/SCREENSHOTS/VIDEO

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

📌 Message to Author

jp-imagines commented 1 year ago

@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 commented 1 year ago

Triage Round Two

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

📌 FINDINGS/SCREENSHOTS/VIDEO

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:

Markup on 2023-05-23 at 13:56:08

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

jeherve commented 1 year ago

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

jeherve commented 1 year ago

related: #22834

github-actions[bot] commented 11 months ago

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

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 commented 10 months ago

Another occurrence: 7447913-zen

monsieur-z commented 3 months ago

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.

Size setting

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
Size setting Size setting

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 commented 3 months ago

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 commented 3 months ago

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 commented 2 months ago

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 commented 2 months ago

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

azaozz commented 2 months ago

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 commented 1 month ago

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.