Closed Bug 132702 Opened 23 years ago Closed 9 years ago

gzip-encoded document not ungzipped before sending to helper app


(Core Graveyard :: File Handling, defect)

Not set


(Not tracked)



(Reporter: kitty, Unassigned)


(Blocks 1 open bug, )


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. 

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.
Assignee: darin → bzbarsky
Component: Networking: HTTP → File Handling
Ever confirmed: true
OS: Linux → All
QA Contact: tever → sairuh
Hardware: PC → All
Priority: -- → P3
Target Milestone: --- → Future
bz: agreed... we need to figure out a plan for this.
*** Bug 145758 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen
*** 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.
Assignee: bz-vacation → file-handling
QA Contact: chrispetersen → ian
Priority: P3 → --
Target Milestone: Future → ---
*** Bug 229870 has been marked as a duplicate of this bug. ***
testcase also available at

bug 57342 will allow fixing this, by always applying the decoding when opening
in a helper app, and not otherwise.

Assignee: file-handling → cbiesinger
Blocks: 229871
Depends on: 57342
Summary: Mozilla doesn't display image in helper app → gzip-encoded document not ungzipped before sending to helper app
since that one actually won't fix this, back to default owner
Assignee: cbiesinger → file-handling
No longer depends on: 57342
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.