Camino saves gzipped html as gzipped files

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
15 years ago
3 years ago

People

(Reporter: devnull, Assigned: mikepinkerton)

Tracking

Trunk
PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20031115 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20031115 Camino/0.7+

On web servers that support gzip compression when Camino is sued to save a file
as "HTML Source Only" the saved file is saved as the compressed data, not the
uncompressed data.

Reproducible: Always

Steps to Reproduce:
1. Navigate to provided URL
2. Save as "HTML Source Only"
3. Open the saved file

Actual Results:  
Camino saves compressed data to disk

Expected Results:  
Camino shold save the uncompressed file to disk

Save as HTML Complete does not exhibit this behavior.

Comment 1

15 years ago
Mozilla acts the same as Camino

Firebird on the other hand saves the file correctly

Maybe a dup of bug 51852. (That might need reopened)

Comment 2

15 years ago
I can confrim this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
this will get fixed when bz lands his stuff on the trunk. over to him so he can
mark as a dupe.
Assignee: pinkerton → bz-vacation
Component: General → File Handling
Product: Camino → Browser
Version: unspecified → Trunk
Er... what stuff?  I have no idea how Save as "HTML Source Only" is implemented
in Camino, but compression issues need to be handled by the embedding app at the
moment.  See the SeaMonkey code at
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/contentAreaUtils.js#265
and
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/contentAreaUtils.js#371

The default operating mode for the persistence object is to NOT decompress
content (see
http://lxr.mozilla.org/seamonkey/source/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp#201).

Back to Mike, but please let me know if there is some reasonable API that we
could expose that would let you not duplicate this sort of logic...
Assignee: bz-vacation → pinkerton
well, this happens in mozilla so it's not a camino issue. bz, ben says you
landed a patch on the fb branch to fix this, but haven't yet landed it on the trunk.

is he on crack?
Assignee: pinkerton → bz-vacation
> well, this happens in mozilla

It does?  On what URL?  With what build?  When I save the URL in the URL field
with Linux nightly build 2004-01-15-07, it works fine.  Are you testing 1.6b or
something silly like that? ;)

> is he on crack?

Yes, as far as I know.  The relevant patch I can think of is bug 228321 (which
was a problem only in 1.6b and is fixed in 1.6 and on the trunk).  Ben would
have had to land this on his branch, since he branched before it went in.  But
_I_ certainly landed nothing on the FB branch.

Like I said, Camino likely needs logic similar to that in the code the patch for
bug 228321 touches.

If, however, there is a url that fails in current Mozilla builds, do feel free
to open up a bug on me; it'll probably need to be separate from this one, since
it will likely be fixed in the SeaMonkey embedding app, not in core code.
Assignee: bz-vacation → pinkerton
Pink is on crack. I said bz landed 220807 on the trunk, a completely different
bug. :D
ok, i spoke with ben and he really is on crack. bz, sorry for the troubles. i
guess we'll look at this more in camino, but that doesn't reconcile Derek's
comment that it happens in mozilla.

derek, which build of mozilla did you try?
Yeah, we need to sort that out, true.

Mike, like I said feel free to poke me if you think the exthandler or something
can expose an api to make this easier...
*** Bug 236680 has been marked as a duplicate of this bug. ***
still an issue in camino 0.8b.
pretty sure we fixed this a couple months ago. it's fixed on the trunk and the
17 branch for 083.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 13

14 years ago
No specific bug / patch referenced as the fix.

-> WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

14 years ago
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.