1583921 - Firefox is downloading all images as webp again

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Moltres Rider]

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

Steps to reproduce:

I am trying to download some jpg files that I need for class. I am giving a presentation on Argentina and ALL the images that I am trying to download are downloading in .webp format which PowerPoint CANNOT use!

you guys said that the issue was fixed (according to the bug report that I filed more than six months ago), but it is STILL happening! I looked in about:config and found that the line I was supposed to delete is still gone so that is NOT the issue!

I opened up https://trip101.com/article/traditional-food-in-argentina

Right clicked some of the food images to save them

Actual results:

Despite the fact that these are jpg files, Firefox is trying to save them as .webp files

Expected results:

Firefox should download these images as the image format that they are originally.

Comment 5

[Alin Ilea, Desktop Test Engineering]

Hi,

I have managed to reproduce this issue on latest FF release (69.0.1), latest Beta 70.0b11 and latest Nightly build 71.0a1 (2019-10-03) using Windows 10 and Windows 7.
I will move this over to a component so developers can take a look over it. From comment 1 it seems this issue is related to bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1530887

Thanks.

Comment 6

[Andy Grover [:grover]]

Baku were you looking into the referenced bug, and if so could you weigh in on this one?

Comment 7

[Andrea Marchesini [:baku]]

Anne, what do you think it should be the right Accept header for images?

So far firefox uses: image/webp,/
Chrome uses: image/webp,image/apng,image/,/*;q=0.8

I haven't checked safari.

Comment 8

[Anne (:annevk)]

Andrea, I don't think this is related to the Accept header (if you think we should change things there, let's do that in a separate bug). Given that OP is using Windows, I suspect this is basically bug 1571247, but OP somehow got WEBP in their registry instead of JFIF.

Comment 9

[:Gijs (he/him)]

Dupe of / related to bug 1526731?

Comment 10

[Anne (:annevk)]

Gijs, as far as I can tell the server here is not sending WEBP, as also mentioned in OP. (Downloading an image on macOS results in a JPG.) That's why that other bug seems more plausible to me.

Comment 11

[:Gijs (he/him)]

(In reply to Anne (:annevk) from comment #10)

Gijs, as far as I can tell the server here is not sending WEBP, as also mentioned in OP. (Downloading an image on macOS results in a JPG.) That's why that other bug seems more plausible to me.

If I right click the first image on the page, click "save image as...", on macOS 70 beta 14, I get offered to save a webp image, and if I use the network inspector and filter on images, aside from the gifs I see a substantial numbers of webp images on initial pageload, despite the URL mentioning png. The Accept header for those image requests is image/webp,*/*, urls like https://trip101.com/assets/logo-thumb-50573e05e348cf236e4e5c074b45c81f8a06a41bb2a63cb738a23237259f5457.png , which if opened on its own shows as a png - but the server says content-type: image/webp when serving it as a result of opening the link in comment #0.

Comment 12

[:Gijs (he/him)]

Put differently, AFAICT we still send image/webp as part of the accept header when requesting images that are in <img> tags or other image contexts inside a HTML document, and this particular server returns the PNG resources but supplies an image/webp content-type, which we happily believe when offering to save the file - presumably imglib doesn't care about the content type and uses magic numbers instead or something, which is (presumably) why we display them despite the wrong content-type.

Comment 13

[Masatoshi Kimura [:emk]]

(In reply to :Gijs (he/him) from comment #12)

presumably imglib doesn't care about the content type and uses magic numbers instead or something, which is (presumably) why we display them despite the wrong content-type.

This behavior is defined in the mimesniff spec. We should determine the file extension based on the computed MIME type (image/png in this case) instead of the supplied one when we save an image.

Comment 14

[:Gijs (he/him)]

(In reply to Masatoshi Kimura [:emk] from comment #13)

(In reply to :Gijs (he/him) from comment #12)

presumably imglib doesn't care about the content type and uses magic numbers instead or something, which is (presumably) why we display them despite the wrong content-type.

This behavior is defined in the mimesniff spec. We should determine the file extension based on the computed MIME type (image/png in this case) instead of the supplied one when we save an image.

Is this computed mimetype currently exposed to (chrome) JS anywhere?

Comment 15

[Masatoshi Kimura [:emk]]

I don't know.

Comment 16

[Anne (:annevk)]

Valentin, you can probably answer comment 14 or know who can?

Comment 17

[Valentin Gosu [:valentin] (he/him)]

(In reply to :Gijs (he/him) from comment #14)

(In reply to Masatoshi Kimura [:emk] from comment #13)

(In reply to :Gijs (he/him) from comment #12)

presumably imglib doesn't care about the content type and uses magic numbers instead or something, which is (presumably) why we display them despite the wrong content-type.

This behavior is defined in the mimesniff spec. We should determine the file extension based on the computed MIME type (image/png in this case) instead of the supplied one when we save an image.

Is this computed mimetype currently exposed to (chrome) JS anywhere?

I think you can get the sniffed mimeType from nsIChannel.contentType - we call the TypeSniffers when the LOAD_CALL_CONTENT_SNIFFERS flag is set, which then sets the sniffed mime type as the contentType of the channel.
I hope this helps.

Comment 18

[:Gijs (he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #17)

(In reply to :Gijs (he/him) from comment #14)

(In reply to Masatoshi Kimura [:emk] from comment #13)

(In reply to :Gijs (he/him) from comment #12)

presumably imglib doesn't care about the content type and uses magic numbers instead or something, which is (presumably) why we display them despite the wrong content-type.

This behavior is defined in the mimesniff spec. We should determine the file extension based on the computed MIME type (image/png in this case) instead of the supplied one when we save an image.

Is this computed mimetype currently exposed to (chrome) JS anywhere?

I think you can get the sniffed mimeType from nsIChannel.contentType - we call the TypeSniffers when the LOAD_CALL_CONTENT_SNIFFERS flag is set, which then sets the sniffed mime type as the contentType of the channel.
I hope this helps.

For all the images I've checked the result for this is image/webp.

But also, all those images when downloaded (by right clicking the image + "save image as", or right clicking the image and then "view image" and then "save file", actually produce a file that file identifies as a webp image, rather than a png or jpeg.

Can someone provide clear steps where they can show we're showing a jpeg or png image that we mistakenly download as a jpeg? (yes, I said in comment #12 that the server returns png - I now think I was wrong and despite the URL displayed (and the finalURI on the channel) indicating "png", we do actually get webp content -- I'll mark the comment obsolete).

Comment 19

[Anne (:annevk)]

On macOS, Firefox Nightly:

1. Visit https://trip101.com/article/traditional-food-in-argentina.
2. Save the image under "1. Locro – traditional Argentinian stew".
3. End up with a .JPG.

(Inspecting headers doesn't tell a different story.)

Comment 20

[:Gijs (he/him)]

(In reply to Anne (:annevk) from comment #19)

On macOS, Firefox Nightly:

1. Visit https://trip101.com/article/traditional-food-in-argentina.
2. Save the image under "1. Locro – traditional Argentinian stew".
3. End up with a .JPG.

(Inspecting headers doesn't tell a different story.)

Following these steps on a clean profile on today's nightly (using the context menu and "save image as") saves a webp for me, also on macOS...

Comment 21

[:Gijs (he/him)]

Per discussion with Anne, it seems the use of jpg may depend on cookies. On a clean profile, the server sends us webp and we offer to save as webp. This is also what other webp-capable browsers do. If you need the images to be compatible with other programs you could use an extension to convert images when saving them.