New issue
Advanced search Search tips

Issue 835688 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Image fails to download in format usable by Windows Photo Viewer

Project Member Reported by rdevlin....@chromium.org, Apr 23 2018

Issue description

Chrome 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.
 
Update:

Doesn't work on 65.0.3325.181
Works on 68.0.3403.0
Maybe there's nothing to be done here, and this has been fixed?  If so, it'd be great to see a duplicate bug and/or a test to prevent regressions.
Status: WontFix (was: Untriaged)
/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.
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?
Cc: cbiesin...@chromium.org
Components: -Blink Blink>Loader
Status: Untriaged (was: WontFix)
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
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.
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.
Owner: qin...@chromium.org
Status: Assigned (was: Untriaged)
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