User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:126.96.36.199) 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:188.8.131.52) Gecko/2009060219 Camino/2.0b3 (like Firefox/3.0.11)
Images contained in webpages when dragged to the Desktop are sometimes corrupt.
Steps to Reproduce:
1.Go to http://www.rapidshare.com/
2. Drag the big rapidshare logo image to your desktop
3. Open it
Couldn’t open the file. It may be corrupt or a file format that Preview doesn’t recognize.
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).
bug 363408 ?
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
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
(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 363408 has been marked as a duplicate of this bug. ***
bug 397002 was the one I was thinking about; I'll forward dupe it here, as we have more details.
*** Bug 397002 has been marked as a duplicate of this bug. ***
*** Bug 495196 has been marked as a duplicate of this bug. ***
Does that also happen with Firefox 184.108.40.206?
(In reply to comment #10)
> Does that also happen with Firefox 220.127.116.11?
I do see the bug with the rapidshare logo using Camino 1.6.10 (Gecko 18.104.22.168), 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.
*** Bug 707600 has been marked as a duplicate of this bug. ***
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]
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]
Good catch. r=me