STR:

1. Have a slack account somewhere.
2. Save the attached "sample EXIF-rotated image" file to your computer.
3. In Slack, use the "paperclip" icon at the right edge of the type-a-comment textfield, to upload an attachment.
4. Choose the EXIF-rotated image from this bug (your saved copy, from step 2)
5. Look at slack's preview rendering of the image

ACTUAL RESULTS:
The image is rotated 90 degrees -- it's displayed tall-and-skinny, with pink on top.

EXPECTED RESULTS:
The image should be shown at its correct EXIF rotation -- short-and-wide, with pink on the left side.

Note: if you proceed and actually post the image, then it's shown correctly in the chat. It's only this "preview" view of it that's wrong.

The problematic 90 degree rotation here is actually a supplemental CSS-transform rotation that slack is adding, with slack mistakenly expectating that the image will be shown at the wrong orientation (due to the old image-orientation:none default) and hence assuming that it needs an additional transform to display properly.

We should probably do some webcompat outreach to Slack folks and see if they can address this on their end by removing the (dynamically added) explicit CSS transform & instead explicitly styling the user-uploaded images with image-orientation:from-image (to make this work the same way regardless of the default value).

Also: it turns out the in-chat image is a server-side-munged file, which has probably had the EXIF data stripped out of it (I'm guessing) and has probably been rescaled/reoriented so as not to have any need for EXIF rotation. So that's why that version of the image works reliably both before and after the change in default behavior.

heycam, what should we do here -- perhaps I shoudl reclassify this as a WebCompat bug & see if we can do some outreach?

(In reply to Daniel Holbert [:dholbert] from comment #2)

We should probably do some webcompat outreach to Slack folks and see if they can address this on their end by removing the (dynamically added) explicit CSS transform & instead explicitly styling the user-uploaded images with image-orientation:from-image (to make this work the same way regardless of the default value).

Sorry, actually this ^^ suggested solution won't work for them if they want to support existing Chromium/Blink versions, because Chromium/Blink apparently didn't support image-orientation at all until now - they implemented it with this new default behavior, and didn't previously support it at all (if I'm reading https://bugs.chromium.org/p/chromium/issues/detail?id=158753#c101 and https://caniuse.com/#search=image-orientation correctly). So image-orientation:from-image won't have any effect in recently-shipping Chrome versions (< 81), so we can't rely on that to do the right thing.

So: I think the simplest band-aid for now would be for Slack to:
(1) add something like .p-pending_image_file__img { image-orientation: none; } to restore the old default orientation behavior for the file-upload preview img element (this matches the orientation that recently-shipping Chrome uses)

(2) adjust their transform scale(...) calculation to account for this change somehow. If I just use .p-pending_image_file__img { image-orientation: none; }, their dynamically-computed transform:...scale(...) value (shown alongside the rotation in the devtools screenshot above) ends up being wrong, because the code that computes it seems to disregard the image-orientation:none setting. (Perhaps that calculation is done via a measurement in a different element which also needs {image-orientation: none; }?)

Note: heycam let me know that Chrome 81 already shipped image-orientation (with default from-image) to release, in version 81. I'd mistakenly thought this change was still working its way through their release channels.

And I just tested in Chrome 81, and I confirmed that they are affected by this bug, as I would expect. So Slack will want to fix this for the benefit of both Firefox 77+ users and Chrome 81+ users.

Here's another image with EXIF-rotation that can be used to test this bug, BTW (this one's a photo so it's easier to immediately see whether it's rotated in a broken way or not).

(Taken from http://sethfowler.org/blog/2013/09/13/new-in-firefox-26-css-image-orientation/ )

I sent a message to my contact at Slack.

Daniel, it is a possibility that since the bug was reported, the page had an UI update, as the paper clip can not be located on my part, on both Chrome and Firefox, as this option is presented:

https://prnt.sc/ETvJkyKNWcIC

If not, could you please provide some extra info in order to locate the paper clip icon, as the said option above does not present the issue when using it.

Tested with:

Browser / Version: Firefox Release 100.0.2 (64-bit)/ Firefox Nightly 102.0a1 (2022-05-26) (64-bit)/Chrome Version Version 102.0.4004.63 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Thanks, this is indeed fixed (on Slack's side).

Their paperclip UI has changed; now the STR would be:

1. Click the "+" icon on the bottom left side of slack's text-entry box
2. Choose Attach|Upload from your computer
3. Choose the image from comment 0 (which you've previously saved to a local file)

And nowadays, slack shows a preview of that image directly in the text-entry box, and it's using the correct rotation (pink on the left).