Closed Bug 1622560 Opened 6 years ago Closed 6 years ago

JPG save is broken in version 74.0

Categories

(Toolkit :: Downloads API, defect)

74 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1602220

People

(Reporter: amsabuncu, Unassigned)

References

()

Details

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #1527043 +++

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 on attachment 9133399 [details] The left shows the image in Firefox 74.0. The right shows image after it has been saved on disk and opened in Windows Photo Viewer Unlike the earlier version of this bug ( Bug 1527043 ), this time the image opens fine in Paint.Net and displays fine. But it displays dark when opened in Windows Photo Viewer. When the image is displayed in Firefox again (i.e. read back from the saved copy), it displays fine. Although it seems that the incorrect format only manifests itself in Windows Photo Viewer, it is still a bug, as images saved in earlier versions displayed fine in Windows Photo Viewer. Thanks.

Downloading that file uses the URL https://static01.nyt.com/images/2019/02/09/nyregion/09xp-island-2/merlin_150364848_83fe9d9f-be8d-4c09-8fa9-493ea9acd30a-superJumbo.jpg?quality=90&auto=webp

See the "auto=webp" (different file format than JPG).

$:acko\> jpeginfo -c merlin_150364848_83fe9d9f-be8d-4c09-8fa9-493ea9acd30a-superJumbo.jpg 
merlin_150364848_83fe9d9f-be8d-4c09-8fa9-493ea9acd30a-superJumbo.jpg  Not a JPEG file: starts with 0x52 0x49  [ERROR]

Not sure this is a bug in Firefox itself.

When I download the same image (same page at nytimes.com) using FF 73.0, it displays fine in Windows Photo Viewer.

So, two versions of FF save the same file in different formats. One displays fine using Windows Photo Viewer, one doesn't.

By the way: When I use jpeginfo on the sound image (i.e. downloaded using FF 73.0), it shows this:
Premature end of JPEG file JPEG datastream contains no image [ERROR]

jpeginfo is difficult to find for Windows, and I got mine from here: http://mattdm.org/misc/jpeginfo-w32/jpeginfo.exe
based on a comment posted for this answer here: https://photo.stackexchange.com/a/46937

Hope this helps.

The priority flag is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

Using Nightly I can't reproduce the problem, recently there have been a series of fixes around webm and jpeg exchanges, so I wonder if this was fixed along with them. Gijs, do you remember which bug changed how we handle downloaded webp?
Is this a dupe of bug 1602220?

Flags: needinfo?(mak) → needinfo?(gijskruitbosch+bugs)

(In reply to Marco Bonardo [:mak] from comment #5)

Using Nightly I can't reproduce the problem, recently there have been a series of fixes around webm and jpeg exchanges, so I wonder if this was fixed along with them. Gijs, do you remember which bug changed how we handle downloaded webp?
Is this a dupe of bug 1602220?

Yes.

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(gijskruitbosch+bugs)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: