Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image Block doesn't display image 'full size' even though this is the default #11529

Open
maddisondesigns opened this issue Nov 6, 2018 · 12 comments
Labels
[Block] Image Affects the Image Block [Feature] Media Anything that impacts the experience of managing media [Type] Enhancement A suggestion for improvement.

Comments

@maddisondesigns
Copy link

Describe the bug
When adding an image to the Image Block, the default Image Size is 'Full Size', but the image doesn't display full size as the div around the img has inline styles for max-width and max-height which are incorrect and therefore restrict the width/height.

Here's how the image dsplays in Twenty Nineteen. It also does the same thing in other default themes.

screenshot_255

Here's the inline styles for that div which restricts the width/height.

screenshot_257

The image displays correctly on the front-end.

Apologies if this has been raised previously. I searched but couldn't find anything related.

To Reproduce
Steps to reproduce the behavior:

  1. Add Image Block
  2. Add large image into block (e.g. image greater than 1500px wide)
  3. Check that Full Size is selected in Image Size dropdown.
  4. See that image doesn't display the full width of the block

Expected behavior
Image should display the full width of the block (when the image size is larger than the block size)

Desktop (please complete the following information):

  • macOS Sierra 10.12.6
  • Firefox Quantum 63.0.1 (64-bit)
  • WP 5.0-beta3-43867
@designsimply
Copy link
Member

designsimply commented Nov 6, 2018

Thank you as always for testing! There is a very large discussion, which I think do think covers the issue you've raised here, happening at #6177. The most recent work on it is showing in #11377. Note: on an initial read, I noticed it says max-width and max-height may match the content_width variable set by a theme, which may explain the part of your experience with seemingly incorrect values for width and height but not count that part as a bug necessarily.

#6177 is indeed a large discussion, and I can see there are recent updates. Have you seen #6177 before and do you agree it covers this case?

@designsimply designsimply added the [Status] Needs More Info Follow-up required in order to be actionable. label Nov 6, 2018
@maddisondesigns
Copy link
Author

@designsimply Thanks for mentioning #6177. I hadn't seen that one. I think that discussion goes a long way to improving the width issues in the editor, but not sure it actually takes this in account.

If you have a look at my screenshots above, you can see that the actual block width is correct, but the issue is that the components-resizable-box__container is what's restricting the width. The main things discussed in #6177 was how better to control the width of the editor (i.e. the size of the blocks) and how best to render the actual image (within those blocks, in the editor and on the front-end). While these will improve things, unless those inline styles are removed from that container, then it's still going to affect how large the image displays within the actual block, not matter what widths are specified on the img tag itself.

I raised #1483 back in June 2017 because of the issues with the editor content width, and in one of my latter comments on that issue, I mentioned that it would be beneficial to be able to specify the content_width along with wide and full widths. It's good to see that they may have come to the same conclusion based on this comment. One of the issues that Gutenberg failed to address right from the very start was the need to allow for different content widths, both on the front-end and in the editor. It seemed to presume that every single page would be 'full width' and failed to take into account pages that included sidebars, and also content that was set as 'wide'. Hopefully #6177 will start to rectify that.

It would be good if this issue could be left open until #11377 is merged to see if it actually does resolve this issue that I mentioned.

@designsimply designsimply added [Type] Enhancement A suggestion for improvement. [Feature] Media Anything that impacts the experience of managing media [Block] Image Affects the Image Block and removed [Status] Needs More Info Follow-up required in order to be actionable. labels Nov 14, 2018
@antpb
Copy link
Contributor

antpb commented May 28, 2020

Hello @maddisondesigns is this still valid? I'm seeing much larger max-width than the original report so I'm thinking that this was resolved with time and iteration. #11377 was split out to smaller PRs and merged so I think this is now fixed. I'm going to close this issue, but if that is invalid or if you're still seeing the issue, let us know and we can reopen. Thanks!

@antpb antpb closed this as completed May 28, 2020
@maddisondesigns
Copy link
Author

@antpb Can you please reopen this. There's still issues when trying to insert an image.

In the following vid you can see that I've inserted an image that's 1707 x 2560 pixels. The Image block defaults the Image Size to the Large version, and changing it to any of the other sizes such as Thumbnail or Full, does nothing. I can't even remove the sizes from the Width and height Image Dimension fields. Each time I try to clear the fields, the block just adds the values back in.

The inserted image remains as the Large (cropped version) even when changing the Size to Full or Thumbnail. There's also inline styles on the surrounding div that set max-width: 1450px; max-height: 2173.94px;.

https://share.getcloudapp.com/5zu10olA

@createscape
Copy link

I'm also seeing this issue on a client's site. He has technical drawings that he needs to display at the original size, but even when the block image is set to full size it only displays at the large size. I checked the CSS and there is nothing wrong there.

@antpb antpb reopened this Jun 1, 2020
@antpb
Copy link
Contributor

antpb commented Jun 1, 2020

Thanks for the updates @maddisondesigns and @createscape . I see now. Opening the issue back up. sorry for the confusion. :)

@createscape
Copy link

Thanks!

@createscape
Copy link

createscape commented Jun 1, 2020

If anyone finds a temporary solution, that would be helpful. I tried adding an image using the classic editor block and it didn't work either with the Full Size option or with the custom size option. Both methods were stuck on the Large image size just like the gutenberg image block.

@createscape
Copy link

It looks like my client's problem was caused by Jetpack's lazy load images feature, rather than the WordPress core.

@paaljoachim
Copy link
Contributor

paaljoachim commented Feb 10, 2021

Testing with
WordPress 5.7 beta 1
Gutenberg plugin 9.9.0 (I am also seeing the result result when Gutenberg plugin is deactivated.)
Chrome
A local test site.

Followed the instructions:

  1. Add Image Block
  2. Add large image into block (e.g. image greater than 1500px wide)
  3. Check that Full Size is selected in Image Size dropdown.
  4. See that image doesn't display the full width of the block

Screen Shot 2021-02-10 at 11 54 39

The result is that I am seeing a max-width of 1450px while the actual image is 1600px x 1600px.


Deactivating the Gutenberg plugin and activating the Classic Editor plugin.
(Testing with an image that is 2480px by 2480px.)

Screen Shot 2021-02-10 at 11 59 37

Conclusion: There seems to be a built in max-width 1450px and a max-height 1450px in Gutenberg. If the Gutenberg plugin is activated or not makes no difference in the result.

@tellthemachines @johnbillion

@tellthemachines
Copy link
Contributor

In the following vid you can see that I've inserted an image that's 1707 x 2560 pixels. The Image block defaults the Image Size to the Large version, and changing it to any of the other sizes such as Thumbnail or Full, does nothing. I can't even remove the sizes from the Width and height Image Dimension fields. Each time I try to clear the fields, the block just adds the values back in.

The only part of this I can reproduce is the width limit when inserting a full size image, which is expected if the image isn't set to alignwide or alignfull and it doesn't have a custom width set.

Setting the image to a smaller size is working for me with the latest version of the plugin. Clearing the image dimension fields also works for me. @maddisondesigns have you tried disabling all other plugins to see if something else may be causing the issue?

@maddisondesigns
Copy link
Author

@tellthemachines There still seems to be multiple issues with the image block. The original issue I raised seems to be working better, but there's other issues that have been introduced since.

If I insert an image and use the Image Size dropdown, the image in the editor now resizes as expected. Also, it replaces the actual image with the correct (resized) image, which is what you'd expect it to do.

If I enter a number in the Width & Height field, the image also changes as expected.

New vid: https://share.getcloudapp.com/kpu7wlWx

With that said, the block still doesn't work reliably. If you insert an image and then change the Width to something large, like 10000, the image extends past the editor and causes horizontal scrolling.

If you use the percentage buttons (25%, 50% etc), and then change the width in the Width field, the image resizes disproportionately.

Both of these issues you can see in the above new video I just created.

As a sidenote, you might want to check to see if the horizontal scrolling is also related to issue #17795 that I raised back in 2019 that still hasn't had any traction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Image Affects the Image Block [Feature] Media Anything that impacts the experience of managing media [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants