1644950 - Offer option / default to re-encoding webp images to png/jpeg when the user saves images that are served as webp/avif

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[ff3lockez]

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

Steps to reproduce:

I went to the Firefox wiki (https://firefox.fandom.com) and clicked on an image that is on the front page of the wiki. This also happens for any other image on any fandom.com or wikia.com website, but I am using the Firefox wiki as an example.

The image opens in the website normally as a .png image, overlaid on top of the rest of the website, and can be downloaded properly. To reiterate, it works correctly if I download the image from here:

https://i.imgur.com/juIgICh.png

However, if I click the "see full size image" link, the website takes me directly to the image. If I try to download it from there, the file gets saved as a .webp file instead of a .png image:

https://i.imgur.com/nfi8msa.png

Actual results:

The URL clearly says .png, yet the file is being saved as a .webp file.

Even if I delete the second half of the URL after .png and hit enter, and then try to save the image file, it still saves it as a .webp file.

Expected results:

The image should be saved as .png instead of .webp.

I understand that wikia is using the webp format to serve this file, and Firefox is accepting it instead of forcing the website to send a backup format. However...

.webp is not a functional image format for end users. The default Windows 10 image viewer, Photos, cannot open it. Photoshop cannot open it without a third-party plugin.

Furthermore, and probably more tellingly, the .webp format was developed by Google and is supported by Chrome, but Chrome doesn't behave like this. Chrome lets users download the file in .png format. Opera, Safari, Edge and Internet Explorer also all save the file as a .png image. Firefox did so two years ago (and did so when wikia's code was written), but no longer does. This is not the website's intended behavior.

Therefore, I believe that this should be classified as a bug.

---

I would like to point out that I've tried the solutions in this top google result, which involve editing the about:config preferences, but they do not fix the problem:

https://support.mozilla.org/en-US/questions/1249717

Removing the webp format from the values of image.http.accept and network.http.accept.default doesn't resolve the problem. Turning off the image.webp.enabled setting just makes these images unable to load in the browser at all - clicking on the "see full size image" link prompts me to download the .webp file instead of opening it in the browser.

Comment 1

[Andrei Purice]

Hello,
I was able to reproduce this on the latest Nightly 79.0a1 (2020-06-14), beta 78.0b7 and release 77.0.1 versions.

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.
Note that the issue is not reproducible on Chrome.

Comment 2

[:Gijs (he/him)]

(In reply to ff3lockez from comment #0)

The URL clearly says .png, yet the file is being saved as a .webp file.

The website sends the image/webp mime type, and also sends a content-disposition header indicating a webp file name, and it sends actual webp content.

Chrome is making an active decision to re-encode as png. I don't know why (and, as far as we can tell, they are re-encoding themselves, because there do not appear to be additional network requests, and the file size and content differs compared to using the chrome developer tools to save the actual response data from the initial load of the image into a tab).

I've tried finding a record of Chrome's decision here, but all I can find searching the web is lots of people complaining about files saving as webp, and suggesting various add-ons to fix this or to allow saving images in custom formats (somewhat orthogonal to webp).

Chrome still saves as webp in other cases - e.g. https://miscmedia-9gag-fun.9cache.com/images/featured/1593006615.4429_mY6EzA_300x158wp.webp still ends up saving as webp. So they don't do this everywhere, and it's not clear when they do and do not do this, and why that decision was made.

Opera, Safari, Edge and Internet Explorer also all save the file as a .png image.

Edge like Edge-based-on-Chromium? Non-Chromium Edge doesn't send image/webp in its accept header, so wikia serves them png files. The other browsers presumably either do the same or don't support webp at all (e.g. Safari, IE).

Firefox did so two years ago (and did so when wikia's code was written), but no longer does.

Because we didn't use to support webp. In fact, until recently, we'd often save things with png/jpeg file extensions in this case - but with webp content, which was a lot worse...

This is not the website's intended behavior.

Websites don't set up images for download, they set them up for viewing, and they use webp to save bandwidth for that viewing in browsers that advertise support. Every single piece of information the webpage sends here (content type header, content-disposition header) points to webp, so that's how we save it.

Removing the webp format from the values of image.http.accept and network.http.accept.default doesn't resolve the problem. Turning off the image.webp.enabled setting just makes these images unable to load in the browser at all - clicking on the "see full size image" link prompts me to download the .webp file instead of opening it in the browser.

Searching the web for "firefox add-on save image png" finds plenty of add-ons that allow you to force re-encoding to png.

Ultimately the question here is whether we should force re-encoding as png or jpeg (or offer an option for this or something). Going to morph to an enhancement request for that functionality.

The same issue will come up for avif. Jon, has this been on your radar at all, and/or do you have any thoughts about this (and/or, do you perhaps know what Chrome is doing here) ?

Comment 3

[Jon Bauman [:jbauman:]]

Sorry, no idea what's going on with Chrome. I asked my AVIF counterpart on the Chrome side and they didn't know either.

I think adding the ability to re-encode to any of Fx's supported formats would be a nice-to-have, but considering that functionality is available in lots of other places, it's probably not going to be a top priority in the near term. I do think it would be valuable to know much much desire there is among users for this sort of functionality so we can properly prioritize it.

Comment 4

[Arun Das]

If adding a built-in converter seems far-fetched, how about re-requesting the image without the image/webp mime type in the accept header?

It could be silent or it could be with user intervention (similar to form submission warning when you refresh a page). The "Save As" dialog could present the PNG or JPG option together with the default WebP option. When the user chooses to save in that option, a warning can be shown:

You have chosen to save this WebP image in PNG or JPEG format. Firefox will need to request the corresponding PNG/JPEG image from the server and download it again. Are you sure you want to continue?
[Yes, request PNG/JPEG format]
[No, save in WebP format]
[Cancel this download]

Furthermore, there could be a user option under Preferences (Settings) to always do this for saved images to help fully automate it for those users who do this frequently. This checkbox could also be in the warning dialog for first-time convenience.

[X] Always request PNG/JPEG images from server when downloading WebP images.

Just an idea :)

Comment 5

[:Gijs (he/him)]

(In reply to Jon Bauman [:jbauman:] from comment #3)

Sorry, no idea what's going on with Chrome. I asked my AVIF counterpart on the Chrome side and they didn't know either.

I think adding the ability to re-encode to any of Fx's supported formats would be a nice-to-have, but considering that functionality is available in lots of other places, it's probably not going to be a top priority in the near term. I do think it would be valuable to know much much desire there is among users for this sort of functionality so we can properly prioritize it.

We now have some data (behind authentication) about download frequencies, and image downloads are actually surprisingly (well, to me!) common. Somewhere around a third of all downloads are images, depending on what formats you count, and jpg is the second most commonly downloaded type of file (after pdf). "webp" and "avif" aren't in our list of types for which we filter, so they get lumped into "other" type downloads for the statistics. In any case, it seems we should at least consider the image downloading usecase as a whole...

Comment 6

[Jon Bauman [:jbauman:]]

(In reply to Arun Das from comment #4)

If adding a built-in converter seems far-fetched, how about re-requesting the image without the image/webp mime type in the accept header?

Better control over that seems like a reasonable thing to add. Right now we have the image.avif.enabled and image.webp.enabled preferences in about:config or directly overriding the image accept header by setting image.http.accept directly (the default, empty value means we dynamically generate it according to whether WebP and AVIF are enabled. However, when we follow the See full size image link, our request in not in an "image" context (that is, not the result of an <img> element), but rather a "document" context so the value we send for the Accept header is different: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8, and as far as I can tell, there's no way to modify this value through preferences.

I'm not opposed to the functionality of re-encoding on save or re-requesting to get a different format, but I think it mostly comes down to a question of prioritization and whether adding it to the UI is worth the cognitive cost of the extra complexity. It does seem like having some way to control the generic Accept header would be worthwhile and the building block for a future feature. I'll file an issue, though I probably won't be able to work on it right away, we'd likely accept patches.

Comment 7

[sagudev [:samson]]

I'm not opposed to the functionality of re-encoding on save or re-requesting to get a different format, but I think it mostly comes down to a question of prioritization and whether adding it to the UI is worth the cognitive cost of the extra complexity. It does seem like having some way to control the generic Accept header would be worthwhile and the building block for a future feature. I'll file an issue, though I probably won't be able to work on it right away, we'd likely accept patches.

What about adding other common image formats under "Save as type" field that is already shown in save dialog. And then if user would for example select PNG from drop down Firefox would convert original image to PNG.

Comment 8

[Jon Bauman [:jbauman:]]

What about adding other common image formats under "Save as type" field that is already shown in save dialog. And then if user would for example select PNG from drop down Firefox would convert original image to PNG.

I don't have any opposition to such a feature if someone wanted to implement it and submit a patch.

Comment 9

[Tomasz Sztejka]

I would like to add my opinion about user experience with *.webp saving.

The user is totally confused when URL seen in an address bar clearly says "*.png" while "Save as" shows him totally different file format. First reaction is: "What the hell have happen? I had to click something wrong!" It appears I didn't. In some "magic conditions" Firefox simply does not let You save png image as png image. Dot. It must be broken, let's try something else.

No one would have complained if URL would be saying "*.webp". It would be completely clear then.

Transport layer is one thing, user layer is an another thing. User experience should be consistent, there should be no "magic side-effects".

Current behavior (81.0.2) would be tolerable if *.webp would be a well recognized format outside browser community. Nowadays it's support is rather poor, so saving as images as webp should be a last resort.

I strongly agree that an absolute minimum is to give users to have exactly the same choice alternatives as were given to servers. You know, humans are a tiny bit more important than machines. I think.