1566316 - HTMLImageElement naturalWidth/naturalHeight does not account for image orientation

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Geoff Lankow (:darktrojan)]

For any image that is rotated 90° or 270° by image-orientation: from-image, the naturalWidth and naturalHeight properties should be swapped. Otherwise, calculations based on the image size are incorrect unless the code somehow knows the image has been rotated.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

I think as filed this is WONTFIX. I don't think we want naturalWidth / naturalHeight to flush layout. But I agree there's something to add here...

https://github.com/whatwg/html/issues/4495 contains similar discussion.

Why was the parity-chrome flag added? Do you have a test-case that works in Chrome? Chrome doesn't support image-orientation at all, as far as I can tell.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

(I'd argue this is DOM since it's about what gets exposed by the API, there's no layout bug to fix here).

Comment 3

[Geoff Lankow (:darktrojan)]

You're right that Chrome doesn't have image-orientation but it appears to have the same behaviour as image-orientation: from-image by default.

As for a test case, a photo taken in portrait mode from most digital cameras.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Ok so this is just about making these respect the exif metadata, regardless of css, right?

Comment 5

[Geoff Lankow (:darktrojan)]

No, because by default we don't rotate the image, so in that case the properties shouldn't change.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

(In reply to Geoff Lankow (:darktrojan) from comment #3)

You're right that Chrome doesn't have image-orientation but it appears to have the same behaviour as image-orientation: from-image by default.

This doesn't match my testing?

• data:text/html,<img src="https://raw.githubusercontent.com/recurser/exif-orientation-examples/master/Portrait_5.jpg"> renders the same in Chrome and Firefox.

• data:text/html,<img src="https://raw.githubusercontent.com/recurser/exif-orientation-examples/master/Portrait_5.jpg" style="image-orientation: from-image"> renders correctly in Firefox, but not Chrome.

Comment 7

[Geoff Lankow (:darktrojan)]

Huh. I'd only been looking at the stand-alone image in Chrome, not in an img tag. They must do something fancy with their stand-alone viewer, because it's just an HTML document with an img tag in it AFAICT. I guess this isn't really a parity issue, which isn't why I wanted it fixed anyway.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Geoff, would an API like naturalOrientation (or something of that sort) fix your use-case? You can query the computed value of the image-orientation property anyway, so you could do something like:

function adjustedImageDimensions(img) {
  let w = img.naturalWidth;
  let h = img.naturalHeight;
  if (getComputedStyle(img).imageOrientation == "from-image") {
    // Update w and h, based on the return value of naturalOrientation. Or something like that.
  }
  return { w, h };
}

The reasons for this are various, but mostly:

• Avoid depending on layout (since it can affect perf).
• Define them properly when e.g., the element is not in the DOM. Otherwise there's no good way to figure out the natural orientation of an image outside of the DOM, which is possible via the the decode() API.

Does that make sense? Alternatively maybe a orientedNaturalWidth / orientedNaturalHeight thing?

Comment 9

[Geoff Lankow (:darktrojan)]

Yes that would be useful, because even in your example getComputedStyle(img).imageOrientation == "from-image" doesn't tell you if an image was rotated, just that it might have been rotated if the EXIF data called for it.

naturalOrientation could be portrait/landscape, or 0/90/180/270 or something like it. IIRC there's 8 possible values in EXIF but I doubt it's necessary to have as much information as that provides.

For both the uses I have in mind, orientedNaturalWidth/orientedNaturalHeight would be sufficient and save an if…else block.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

It'd be great if you left a comment with your use case in the HTML spec issue, fwiw :)

Comment 11

[Franpa_999]

I've experienced this issue with several releases of Firefox, specifically images hosted on Discord trigger the problem when they are manipulated by Zoom Page WE add-on.

To reproduce:

1. Install Firefox for Windows Desktop PC.
2. Install Zoom Page WE
3. Configure Zoom Page WE to match this configuration: https://imgur.com/yUNlcHL
4. Open an image hosted on discord, such as: https://cdn.discordapp.com/attachments/129399825342005250/612401472025657344/image0.jpg or alternatively https://cdn.discordapp.com/attachments/129399825342005250/574403266293792809/20190504_195328.jpg

The image aspect ratio will be inverted.

Comment 12

[Franpa_999]

(In reply to Franpa_999 from comment #11)

I've experienced this issue with several releases of Firefox, specifically images hosted on Discord trigger the problem when they are manipulated by Zoom Page WE add-on.

To reproduce:

1. Install Firefox for Windows Desktop PC.
2. Install Zoom Page WE
3. Configure Zoom Page WE to match this configuration: https://imgur.com/yUNlcHL
4. Open an image hosted on discord, such as: https://cdn.discordapp.com/attachments/129399825342005250/612401472025657344/image0.jpg or alternatively https://cdn.discordapp.com/attachments/129399825342005250/574403266293792809/20190504_195328.jpg

The image aspect ratio will be inverted.

Example of what firefox displays under this condition: https://imgur.com/5P6co9a

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Well, it seems to me that that add-on is relying on a blink hack, which explicitly says: "If this is an image document, then use the exif data, otherwise don't"

Comment 14

[Cameron McCormack (:heycam)]

With image-orientation: from-image soon to be the default, I tend to agree that naturalWidth and naturalHeight should honor the EXIF orientation of the image.

Comment 15

[Cameron McCormack (:heycam)]

Taking this to ensure it is resolved before bug 1607667 makes it to beta.

Comment 16

[Cameron McCormack (:heycam)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f809e87f6ba484cb04dec1e18274aff2af576ef5

Comment 17

[Cameron McCormack (:heycam)]

Attachment: Bug 1566316 - Make naturalWidth/naturalHeight on images honor orientation metadata.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/84726c335808
Make naturalWidth/naturalHeight on images honor orientation metadata. r=emilio

Comment 19

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/22771 for changes under testing/web-platform/tests

Comment 20

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 21

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/84726c335808

Comment 22

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot