New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 760612 link

Starred by 5 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

HTMLImageElement natural dimensions incorrect for image with sizes

Reported by oliverj...@gmail.com, Aug 30 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.25 Safari/537.36

Steps to reproduce the problem:
Example: http://jsbin.com/lupicuq/4/edit?html,js,output,console

What is the expected behavior?
HTMLImageElement.natural{Width,Height} should return the image's natural dimensions before `sizes` is applied (750px, when image is constrained to 200px via `sizes`).

What went wrong?
HTMLImageElement.natural{Width,Height} returns the image's dimensions after `sizes` is applied (200px).

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 61.0.3163.25  Channel: n/a
OS Version: OS X 10.12.6
Flash Version: 

Firefox has the same behaviour, Safari does what I would expect.

I'm not sure what the correct behaviour is.
 
Cc: kkaluri@chromium.org
Labels: Needs-Triage-M61 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 with chrome stable #61.0.3163.79, Canary #63.0.3207.0 and also in earlier version M50-#50.0.2661.0. This is a non-regression issue hence marking it as untriaged.

Attaching a screen-cast for reference.
760612.mp4
358 KB View Download
Components: Blink>Image
Status: Available (was: Untriaged)
I can reproduce the indicated behavior. I agree that it seems naturalWidth should
not be affected by "sizes".

Note that Firefox has the same behavior as Chrome on this example.
Labels: -Pri-2 Pri-3

Comment 4 by f...@opera.com, Oct 3 2017

AFAICT, this is the specified behavior. It's a bit contorted, but I'll try to give a walkthrough of the relevant spec sections...

HTMLImageElement.natural{Width,Height} is defined as [1]:

  "...must return the density-corrected intrinsic width and height of the image, in CSS pixels, if the image has intrinsic dimensions..."

Note the term "density-corrected intrinsic <foo>" here. This is defined as [2]:

  "...the intrinsic width and height after taking into account the current pixel density."

The 'current pixel density' in turn is would come from the selection of an image source [3]**, and in this particular case from the 'normalise the source densities' step [4], where the following will apply:

  "Otherwise, if the image source has a width descriptor, replace the width descriptor with a pixel density descriptor with a value of the width descriptor value divided by the source size and a unit of x."

which would give a density of 750 / 200, and thus yield "200" for naturalWidth.

[1] https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-naturalwidth
[2] https://html.spec.whatwg.org/multipage/images.html#density-corrected-intrinsic-width-and-height
[3] https://html.spec.whatwg.org/multipage/images.html#select-an-image-source
[4] https://html.spec.whatwg.org/multipage/images.html#normalise-the-source-densities

** It looks a bit as if the updating-the-image-data algorithm doesn't update 'current pixel density' after step 8 though as I would expect...
I'm facing the same issue. The value of the sizes attribute influences the value of naturalWidth. 

Comment 7 by l...@chromium.org, Jun 6 2018

Cc: divya.pa...@techmahindra.com l...@chromium.org
 Issue 788114  has been merged into this issue.

Comment 8 by l...@chromium.org, Jun 6 2018

Cc: lushnikov@chromium.org
 Issue 630552  has been merged into this issue.

Sign in to add a comment