132702 - gzip-encoded document not ungzipped before sending to helper app

Status: RESOLVED WONTFIX

(Core Graveyard :: File Handling, defect)

Description

[Krishnakumar B]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Darin Fisher]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[David G King]

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

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

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