Image fails to download in format usable by Windows Photo Viewer |
||||
Issue descriptionChrome Version : 65.0.3325.181 OS Version: Windows 7, Windows 10 URLs (if applicable) : http://st.hotrod.com/uploads/sites/21/2017/12/01-1932-ford-highboy-two-door-sedan-triple-crown-of-rodding-poteet-johnson.jpg Other browsers tested: Microsoft Edge (Win 10): OK (ish - see steps below) What steps will reproduce the problem? 1. Visit http://st.hotrod.com/uploads/sites/21/2017/12/01-1932-ford-highboy-two-door-sedan-triple-crown-of-rodding-poteet-johnson.jpg (the image displays a-okay) 2. Right click -> Save image as 3. Try to open downloaded file (which should be a JPEG) What is the expected result? Window opens in Windows Photo Viewer What happens instead of that? Windows Photo Viewer says "Windows Photo Viewer can't open this picture because the file appears to be damaged, corrupted, or is too large." Please provide any additional information below. Attach a screenshot if possible. Fun facts: - Edge works, but downloads the image as a .png instead of a .jpg. I wonder if they do some kind of image conversion before downloading which preserves the file? - Re-opening the file in Chrome actually works just fine. (See below) This could easily be a problem in photo viewer instead of Chrome, but the fact that the image doesn't work when downloaded from Chrome, but does when downloaded from Edge, isn't a good UX for Chrome. If Edge is in fact just re-encoding the image before download, maybe there's something there to be learned? Or if we're packaging it wrong, maybe that's something we could do better. Assigning optimistic labels that are probably wrong; please recategorize as appropriate.
,
Apr 24 2018
/tmp/01-1932-ford-highboy-two-door-sedan-triple-crown-of-rodding-poteet-johnson.jpg: RIFF (little-endian) data, Web/P image So the server is actually sending Chrome a WebP image, which we then save. Not much we can do about that.
,
Apr 24 2018
Interesting. Does the server send a different image for M68 vs M65? (Because Canary worked, but M65 didn't.) Is the behavior change there expected?
,
Apr 25 2018
I was using M67... I don't know if the behaviour change is expected. I guess over to Loader in case the accept header changed unexpectedly or something
,
May 3 2018
Perhaps the server is checking the user agent or the headers to see whether or not webp is supported and returning different content. I don't know if there is anything we should do here. I don't think we want to change encoding on the fly.
,
May 3 2018
I'm totally willing to accept "server did something silly" as a viable outcome. :) I just found it funny that it worked on Canary (and Edge, but I think they are doing re-encoding), but not Stable. If it was just a quirk... works for me.
,
May 10 2018
Oh interesting sorry I missed that! Min, can you try hardcoding trunk's user agent to the stable version and see if it still fails? |
||||
►
Sign in to add a comment |
||||
Comment 1 by rdevlin....@chromium.org
, Apr 23 2018