Offer option / default to re-encoding webp images to png/jpeg when the user saves images that are served as webp/avif
Categories
(Firefox :: File Handling, enhancement)
Tracking
()
People
(Reporter: ff3lockez, Unassigned)
References
Details
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•4 years ago
|
||
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•4 years ago
|
||
(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) ?
Updated•4 years ago
|
Comment 3•4 years ago
|
||
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.
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•4 years ago
|
||
(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•4 years ago
|
||
(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.
Updated•4 years ago
|
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•4 years ago
|
||
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 hidden (advocacy) |
Description
•