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.

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

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:
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):
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.
@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.
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 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;.
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.
Thanks for the updates @maddisondesigns and @createscape . I see now. Opening the issue back up. sorry for the confusion. :)
Thanks!
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.
It looks like my client's problem was caused by Jetpack's lazy load images feature, rather than the WordPress core.
Most helpful comment
@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__containeris 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 theimgtag 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_widthalong 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.