From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows NT 5.0) I am not using Windows but Mozilla get this as Windows. I am using Linux 2.4.18 on an i686 BuildID: 2002032108 When I click on the above link Mozilla doesn't display the image. Sometimes the image download returns immediately. When I check /tmp, the file is 0 bytes. Some fix has landed in Mozilla which makes the cache work right. So if I try to download the same file again by clicking, Mozilla doesn't start the download again. A window appears briefly and disappears almost immediately. When sometimes Mozilla does download the file, it is not able to spawn the helper app that I specify. I checked with Netscape and it displays the image in ee perfectly. Seems to be related to fix for bug 119094. This is not a profile issue as I started with -profileManager and created a new profile and tried it again. I also deleted all the helper apps in my old profile and tried. Still no luck. In general, downloading huge files (read as mozilla-i686-pc-linux-sea.tar.gz)/ images by either shift-clicking or storing helper apps in Mozilla sucks. See bug 121532. I keep getting hangs every once in a while when trying to get a new nightly build. In fact nowadays that is the only time I have to kill Mozilla i.e to install a newer version. It would be nice if downloading files via Mozilla 1.0 would be stable. Reproducible: Always Steps to Reproduce: 1.Click on above link. 2.Specify ee as helper app in the dialog box. 3. Actual Results: ee **** out with the message Gdk-WARNING **: locale not supported by C library gdk_imlib ERROR: Cannot load image: /tmp/coplien.tiff.gz All fallbacks failed. See /usr/share/doc/gdk-imlib1/README.fallback. Expected Results: Mozilla should download the image properly i.e should not leave a 0 byte file or a gzipped file.

The image is content-encoded but we don't decode it because it ends in .gz. So we pass off a gzipped file to ee (Bill, this was the worry you expressed about that content-encoding patch I landed the other day -- the one I said was not as likely to be an issue as the alternative). There is really nothing we can do here until we know whether we're saving or opening with a helper _before_ we have to choose whether to decode... Taking this, but I see no way to fix this till the whole arch of the helper app handler is fixed.

bz: agreed... we need to figure out a plan for this.

*** Bug 145758 has been marked as a duplicate of this bug. ***

*** Bug 202708 has been marked as a duplicate of this bug. ***

*** Bug 204422 has been marked as a duplicate of this bug. ***

No plans to work on this any time in the foreseeable future, so to default owner.

*** Bug 229870 has been marked as a duplicate of this bug. ***

testcase also available at http://biesi.damowmow.com/word.php.gz bug 57342 will allow fixing this, by always applying the decoding when opening in a helper app, and not otherwise. taking

since that one actually won't fix this, back to default owner