User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:18.104.22.168) Gecko/2009060219 Camino/2.0b3 (like Firefox/3.0.11) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:22.214.171.124) Gecko/2009060219 Camino/2.0b3 (like Firefox/3.0.11) Images contained in webpages when dragged to the Desktop are sometimes corrupt. Reproducible: Always Steps to Reproduce: 1.Go to http://www.rapidshare.com/ 2. Drag the big rapidshare logo image to your desktop 3. Open it Actual Results: Couldn’t open the file. It may be corrupt or a file format that Preview doesn’t recognize. Expected Results: The file should open in Preview like it happens when Safari is used. This is not a problem with all images but I have encountered this problem many times on different websites.
It is not only Camino. Firefox (3.0.x and newer) is equally affected. There is dupe somewhere, I think. On Rapidshare at least, the image is gzipped. Somehow drag&drop doesn't unzip the image. Right click, 'save as' works correctly though.
I don't see any gzip headers sent with that image when I 'curl -I' it, which could be the problem. As far as the dupe, there's bug 495196, but it's unusable as a bug for fixing anything ;) According to that bug, though, the problem is Mac-only, so kicking to Widget:Cocoa for further triage (but the example in that bug WFM, but it also sends no gzip headers).
Fwiw - right click on the image and copy, then paste in Preview.app works fine. (In reply to comment #2) > I don't see any gzip headers sent with that image when I 'curl -I' it, which > could be the problem. I see it with the LiveHTTPHeaders extension on Minefield HTTP/1.x 200 OK P3P: CP="ALL DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa CONa TELa OUR STP UNI NAV STA PRE" Date: Sun, 16 Aug 2009 00:28:59 GMT Connection: close Accept-Ranges: bytes Content-Type: image/gif Expires: Sun, 16 Aug 2009 00:58:59 GMT Set-Cookie: user=; domain=.rapidshare.com; path=/; expires=Mon, 21-Nov-1994 16:01:23 GMT Content-Encoding: gzip Content-Length: 3857
(In reply to comment #4) > > I don't see any gzip headers sent with that image when I 'curl -I' it, which > > could be the problem. > > I see it with the LiveHTTPHeaders extension on Minefield Could certainly be that the server adds it depending on UA or other accept-* headers. (In reply to comment #3) > bug 363408 ? Sounds like Jo wins the prize (and dolske the goat for filing in Firefox, but to be fair I suspect he wasn't working on Firefox back then) ;) I think we have marginally more info here (namely that's it really only drag-drop; copy/paste works, so it's got to be in the code that's not shared between the two), so going to confirm this one and dupe dolske forward.
bug 397002 was the one I was thinking about; I'll forward dupe it here, as we have more details.
Does that also happen with Firefox 126.96.36.199?
(In reply to comment #10) > Does that also happen with Firefox 188.8.131.52? I do see the bug with the rapidshare logo using Camino 1.6.10 (Gecko 184.108.40.206), and dolske's dupe was set to "2.0 branch" in the Firefox product. I assume it's a bug in the Mac drag code from time immemorial.
This is actually a bug in core code, but the code seems to only be used by Mac at the moment (at least for image dropping).
Created attachment 582035 [details] [diff] [review] patch This fixes the bug, by having the webbrowserpersist that's used for dropped files on some platforms automatically handle conversion as needed.
Comment on attachment 582035 [details] [diff] [review] patch Good catch. r=me