1527043 - JPG save is broken in version 65

Status: RESOLVED WORKSFORME

(Toolkit :: Downloads API, defect)

Description

[Toddintr]

Attachment: merlin_150364848_83fe9d9f-be8d-4c09-8fa9-493ea9acd30a-superJumbo_FF_65.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

1. Visit: https://www.nytimes.com/2019/02/09/science/tonga-island.html
2. Right click on the last image on the page and save it to disk. The filename of the image is merlin_150364848_83fe9d9f-be8d-4c09-8fa9-493ea9acd30a-superJumbo.jpg
3. Open the image in Windows Photo Viewer.
4. Attempt to open the image in Paint.Net or Photoshop CC.

Actual results:

When viewed in Paint.Net, the saved image is displayed in much darker form:

If you try to open the image in Photo.Net or Photoshop CC, error is received saying the image is corrupted and will not be displayed at all.

Happens with all images hosted at the New York Times site. I do not know if the problem exists with images saved from other websites.

There is NO problem with the image displayed by Firefox 65 itself. The image shows fine. The problem only happens when the image is saved on disk.

Expected results:

In version 64, the images are being saved correctly. The following link shows a screen capture of two images (from 64 and 65) side-by-side as displayed by Windows Photo Viewer:

https://postimg.cc/Wt4dPwHW

Also, I am attaching the version 65 image which is the one with the problem.

Note: I have downgraded to version 64 and have disabled auto-updates.

Comment 1

[Toddintr]

Additional comment:

Indeed, Firefox itself cannot display the image that it just saved! It produces the following error:

The image "file:///C:/Users/.._FF_65.jpg" cannot be displayed because it contains errors.

Comment 2

[Sayed [:LiquidO2]]

I have saved the last image from the link provided with Firefox 65 in Windows 10 and I can open it using Firefox and Windows photo viewer without any issue. However when opening with Paint.net app, it shows error.

After saving the same image using latest Nightly 67(build id: 20190211092917), the image opens with Paint.net app as well.

Investigating further, I see that the file downloaded with Release is 784KB but when downloaded with Nightly, it is 740KB (which is same when downloaded with Chrome). Another difference between these two is that when opened with Firefox and checked image info (right click on the image > image info > select the image from the list) the one that is downloaded with ff67 shows Type: JPEG Image which is expected but the ff65 one shows Type: WEBP Image which is not expected.

I am marking this as new since the file downloaded with Release 65 does not have expected properties.

Comment 3

[Toddintr]

@Sayed:

Thanks for your activities confirming the problem. Based on your findings, I renamed the extension of the problematic file (saved with version 65) from jpg to webp. Chrome was able open and display the file correctly (no darkness encountered).

As I am now running version 64, Firefox was not able to open the file with the webp extension.

Hope this additional information helps. Thank you.

Comment 4

[Toddintr]

Incidentally, here's a direct link to the image at NYT website:

https://static01.nyt.com/images/2019/02/09/nyregion/09xp-island-2/merlin_150364848_83fe9d9f-be8d-4c09-8fa9-493ea9acd30a-superJumbo.jpg

Comment 5

[Matthias Versen [:Matti]]

13:17.56 INFO: No more inbound revisions, bisection finished.
13:17.56 INFO: Last good revision: 754cc91c9d3b50207679ef25861d662496811c64
13:17.56 INFO: First bad revision: 243ce783ccfb0f05c85d1575d26e8e845cfd1eb2
13:17.56 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=754cc91c9d3b50207679ef25861d662496811c64&tochange=243ce783ccfb0f05c85d1575d26e8e845cfd1eb2

The problem is that the page sends as a Webp image instead of a jpg when using save image as.
The result is a webp image on the disk with a jpg file extension.
You can check that yourself if you open the saved image (which works due to content sniffing) and open the image properties from the context menu. The dialog shows that the image is a webp image.

We have bug 1347958 and the http accept header got also changed back to not explicit include image/webp and that fixed the bug.
I therefore mark this report wfm