Open Bug 1644950 Opened 4 years ago Updated 26 days ago

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

Categories

(Core :: Graphics: ImageLib, enhancement)

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.

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.

Status: UNCONFIRMED → NEW
Component: Untriaged → File Handling
Ever confirmed: true

(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) ?

Type: defect → enhancement
Flags: needinfo?(jbauman)
Summary: Images from wikia.com and fandom.com get saved as .webp → Offer option / default to re-encoding webp images to png/jpeg when served as webp/avif
Summary: Offer option / default to re-encoding webp images to png/jpeg when served as webp/avif → Offer option / default to re-encoding webp images to png/jpeg when the user saves images that are served as webp/avif

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.

Flags: needinfo?(jbauman)

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 :)

(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...

(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.

Depends on: 1658008

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.

Flags: needinfo?(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.

Flags: needinfo?(jbauman)

Moving to Core :: Graphics: ImageLib, as :Gijs said in chat:

I believe we'll need platform support to offer this option.

Component: File Handling → Graphics: ImageLib
Product: Firefox → Core
Version: 77 Branch → Trunk
Duplicate of this bug: 1831408
Duplicate of this bug: 1896602

For some added context, from one of the dupes:

(In reply to Timothy Nikkel (:tnikkel) from bug 1896602 comment #6)

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

Well, in both the cases I'm thinking of (for image context menu + file save as) we already have a rendered image at the point where the user asks to save it. So I feel like it'd be easier to tackle the issue before we save a copy to disk (or we might run into issues with disk space, not being allowed to move/remove files on/across certain types of file systems, etc.). Would that also work, ie could frontend ask imgITools or similar to do the re-encoding based on the image in the content area, or is there a reason that's a bad idea? :-)

Hmm, that does seem much simpler! And I can't think of a reason why not to do it, after all we would be doing a similar thing for copying the image to the clipboard already.

So I think we'd want some kind of API on imgITools or similar to get a jpg/png blob/arraybuffer that we can write to disk.

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

In the Chrome bug, I proposed that the site could just look at Sec-Fetch-Dest and serve a "more compatible" format if the value is "empty" (as it is during a Save Image As), reserving the higher-efficiency formats for when Sec-Fetch-Dest is "image", reflecting an in-page image.

Interestingly, however, this does not seem to work in Firefox. Even if I serve the image with a Vary: Sec-Fetch-Dest response header, Firefox does not make another request to the server.

Test page: https://webdbg.com/test/SaveTargetAs/#imageDestination

Indeed, 4 years ago, Chrome was downloading the wrong format on right click.

However, this was a bug, not a feature. It has since been fixed.

See https://issues.chromium.org/issues/40195414

(For context, I'm coming here from https://bugzilla.mozilla.org/show_bug.cgi?id=1896602.)

(In reply to styfle from comment #15)

Indeed, 4 years ago, Chrome was downloading the wrong format on right click.

However, this was a bug, not a feature. It has since been fixed.

See https://issues.chromium.org/issues/40195414

Just to make sure I understand: are you suggesting that Firefox's behaviour is correct with regards to this?

(from comment #14)

Even if I serve the image with a Vary: Sec-Fetch-Dest response header, Firefox does not make another request to the server.

I ask because if this was considered a bug in Firefox then this is functionality we would look to use at Unsplash. Although it only solves half of the problem I described in my issue i.e. the issue remains for drag and drop.

Just to make sure I understand: are you suggesting that Firefox's behaviour is correct with regards to this?

I haven't tested every case for Firefox to confirm that. But I wanted to note that the original Firefox issue is comparing to Chrome from 4 years ago. And Chrome has since changed behavior so many of the comments above no longer make sense since believe Chrome and Firefox behave the same today, at least based on this test: https://issues.chromium.org/issues/40195414#comment16

In my opinion, "Save Image As..." should never make a new http request - it should always save the image as it was rendered. That's why its called "Save" and not "Download".

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.

This sounds reasonable to me because the user is making a conscience decision. Although a website can already achieve this with a download button.

Perhaps in the case of Upstash, the download button is not in a discoverable place?

… a website can already achieve this with a download button.

Perhaps in the case of Upstash, the download button is not in a discoverable place?

You might be right that the download button is not easily as discoverable as it perhaps should be. However, even if discoverability was the issue here, fixing that wouldn't help users who prefer to download using other methods such as drag and drop.

I'm also trying to avoid making assumptions about all the way a user can save/copy an image, across all device factors, because there's probably methods I'm forgetting or unaware of. Another one that comes to mind is tap + hold on mobile.

You need to log in before you can comment on or make changes to this bug.