What were you doing?

1. Go to https://www.gamestar.de/spiele/endzone-a-world-apart,14184.html
2. Inspect one of the images in the list called "AKTUELLES"
3. Hover over the URL of the image URL of the src attribute of the <img> element

What happened?

The size of the image element (229 × 129) is shown.

What should have happened?

The intrinsic size of the image (actual size depends on which image is loaded in the end but e.g. 446 × 251) should be shown like it happens for other images.

Anything else we should know?

I couldn't come up with a smaller test case so far, e.g. data:text/html,<style>img{width:320px;}</style><script>window.addEventListener("load",function(){document.querySelector("img").setAttribute("src", "https://i.picsum.photos/id/450/640/400.jpg");});</script><img src=""> shows the correct intrinsic size of 640 × 400. I assume it must be related to the lazy loading mechanism used on that page.

Sebastian

I'm having difficulty reproducing this. I see the 472 x 266 side on hover over the src attribute. Perhaps I am not following the precise steps you are taking to see this bug. Would you please attach a short screen recording showing the bug?

Thanks for coming back to me, Brad! I just realized it actually depends on the viewport size, so please try to resize the window and hover the image again. At some point you should see the dimensions mentioned earlier.
In any case, I've also attached you a video, in which I'm showing the steps described before and comparing the dimensions shown in the tooltip with the expected ones.

Sebastian

I still am not able to reproduce following your steps, not at any window size. I've tested with a clean profile. I'm testing on macOS. It's possible (but not likely) this bug is platform-specific. I'll find somebody else to test this on Windows.

Ah, this also depends on the screen's DPI. In case you have a high resolution screen, turn on RDM and set the DPI to 1. Hopefully it's then possible for you to reproduce the issue.

Sebastian

I can reproduce something like this in RDM by manipulating the DPR value. When I do that, I get differing values for the intrinsic size of the image, as reported by the highlighter in the devtools Inspector. But the original bug wasn't reported in RDM so I'll keep trying with different device resolution settings in a regular browser window to see if I can replicate there. I don't want to characterize this as an RDM bug if it's more general.

Keeping the needinfo open on me so I can complete the triage of this problem.

Thank you for investigating further! Meanwhile I could finally reduce it to a simple test case:

data:text/html,<style>img{width:400px;}</style><img src="https://picsum.photos/id/1037/400/240" alt="" sizes="100px" srcset="https://picsum.photos/id/1037/400/240 400w">

So the width defined in the sizes attribute (100px in the example) is used to calculate the sizes shown in the tooltip and not the actual intrinsic size of the image being loaded (400px). And removing the sizes attribute, the tooltip uses the viewport width as reference.

The expected behavior is that the tooltip always shows the intrinsic image size of 400 × 240, no matter what value is set for the sizes attribute. That attribute is only an indicator for the browser for which image of the srcset attribute to display under certain conditions.

I am removing the need-info as you should now be able to reproduce it.

Sebastian

The priority flag is not set for this bug.
:gl, could you have a look please?

For more information, please visit auto_nag documentation.

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #7)

The priority flag is not set for this bug.
:gl, could you have a look please?

For more information, please visit auto_nag documentation.

Brad, I think I am leaning towards a P2, but I will let you be the final judge of that.

Reading the code and the specification, I finally understand what's going on here.

The tooltip shows the values of the naturalWidth and naturalHeight of the image, which are its density-corrected intrinsic sizes.

And that sizes are used as natural dimensions for the image.

So after all, the displayed dimensions are not wrong per se, and may actually be valuable when using the images on the page. Though authors may rather expect to see the intrinsic/source width and height of the image.

Therefore I close this bug now in favor of creating a new one to add the intrinsic image dimensions as the main info to the tooltip but keep the natural dimensions as secondary info.

Sebastian