1619576 - image with bogus EXIF orientation data is shown incorrectly

Status: RESOLVED WONTFIX

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

Description

[Andrew Gaul]

Attachment: Firefox desktop nightly.png

When viewing http://cardhouse.com/where/jejune.htm the first image is rotated 90 degrees counter-clockwise when viewed in Firefox desktop nightly and Firefox Android Preview nightly. However it is displayed correctly (text horizontal) in Firefox Android classic and Chrome.

Comment 1

[Andrew Gaul]

Attachment: Firefox Android Preview nightly.jpg

Comment 2

[Andrew Gaul]

Attachment: Firefox Android classic nightly.jpg

Comment 3

[Andrew Gaul]

Attachment: Chrome 80.jpg

Comment 4

[Andrew Gaul]

Attachment: one-microwave.jpg

Comment 5

[:Gijs (he/him)]

Tested in 74 beta where things work correctly, so this seems to be a recent-ish regression - or a pref/config difference between beta and nightly.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

This is the other way around, that image has bogus exif information. Chrome Canary also shows the same as Firefox.

This is a regression from bug 1607667. This is the second one and it's been on Nightly only for a couple weeks... Maybe we should reconsider?

Comment 7

[Cameron McCormack (:heycam)]

If this is indicative of some tooling or workflow (or perhaps digital camera output) that results in JPEGs with bogus EXIF information, then that would start to concern me. I'm inclined still to wait until beta, at which point Chrome's equivalent change will be rolled out to release, and we can assess then.

One interesting thing I noticed with this image is that the raw image data size (600x799) does not match the aspect ratio of the Image Width / Image Height EXIF tags (3648x2736). That's consistent with a tool that rotates the raw image data but doesn't touch any EXIF metadata. Same for Jens' image. The EXIF spec says these two tags are ignored because the image dimensions in JPEG markers are used instead. But if they are present, and their aspect ratio is the inverse of the raw image data size, and there is a rotation specified in the Orientation tag, maybe that's sufficient to identify images that will be shown "incorrectly"?

Comment 8

[Jens Stutte [:jstutte]]

Hi Cameron, do we have now a better understanding if we should act on our side?

Comment 9

[Ryan VanderMeulen [:RyanVM]]

IIUC, this was fixed by backout for Fx75. Given our desire to minimize potential breaking changes at the moment, I'm wondering if we should at a minimum restrict this change to Nightly only while we work out the kinks?

Comment 10

[Julien Cristau [:jcristau]]

See bug 1623820.

Comment 11

[Sean Voisen (:svoisen)]

Assigning to heycam since he owns this project. Per comment 9 and comment 10, this will be held to Nightly for now.

Comment 12

[[:philipp]]

[Tracking Requested - why for this release]:
bug 1623820 which was supposed to make the change nightly only got backed out from 76, so it's still affected. how are supposed to progress here?

Comment 13

[Cameron McCormack (:heycam)]

Right, this is still WONTFIX per our current plan. Andrew, you can fix this for your site by adding img { image-orientation: none; } to your CSS.

If we eventually find there are too many of these broken images, we can think about how to ameliorate the problem by adding some heuristics. But for now, we're likely to just follow Chrome's choice in whether this change will stick.