Closed Bug 221877 Opened 21 years ago Closed 21 years ago

Camino (Mozilla) opens downloads (.dmg or .gz) in the content view.

Categories

(Camino Graveyard :: Downloading, defect)

Product:
Camino Graveyard
Component:
Downloading
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 220807

People

(Reporter: camino, Assigned: mikepinkerton)

References

(
URL
)

Details

Attachments

(1 file, 1 obsolete file)

still likely to never be accepted
5.02 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030617 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/200310 Camino/0.7+

I have hit several instances where clicking on a link that refers to a
downloadable file doesn't pass the download to the download manager but opens
the file in the content view.

http://adium.sourceforge.net/downloads/Adium_10-09-2003.dmg
http://ftp-new.mozilla.org/pub/camino/nightly/latest/Camino.dmg.gz

Reproducible: Always

Steps to Reproduce:
1. Go to one of the 2 urls given.
Actual Results:  
The files are loaded in the comtent area, as if they where html files. This
causes Camino to become unresponcive as long as the file is being loaded.
Finally the .dmg or .gz file is displayed as a binary file (code).

Expected Results:  
Camino should always pass (.dmg .gz) files to the download manager, unless they
are texta pages and not more that 1/2mb in size.

I asume there already is a bug filed on this but I can't find it. Sorry for the
spam.
curl -I http://adium.sourceforge.net/downloads/Adium_10-09-2003.dmg
HTTP/1.1 200 OK
Date: Sun, 12 Oct 2003 15:32:03 GMT
Server: Apache/1.3.26 (Unix) PHP/4.1.2
Last-Modified: Thu, 09 Oct 2003 17:24:38 GMT
ETag: "166269-285c79-3f8599d6"
Accept-Ranges: bytes
Content-Length: 2645113
Connection: close
Content-Type: text/plain    <-- there's your problem ;-)

This is evang.
I suspcted this to be the case. But I was wondering, why is it that other
browsers such as Safari do handle that same file correctly by passing it to the
downloads manager? You can't tell me that Mozilla isn't smart enough to figure
out I'd rather have a 7mb large file in the dl manager than in the content view.
I know Mozilla is doing the right thing here (content type set by the server),
but wouldn't it be more user friendly to have a quirk mode for downloads to?
Bug 175848 had a rancorous discussion about this behavior.  The conclusion was
that Mozilla correctly honors the text plain content type sent by misconfigured
servers for .dmg and .gz.  So it's not a bug, it's a feature to help users
identify misconfigured servers.

Unfortunately, 99% of the world's servers seem to be misconfigured, such as:

http://ftp.mozilla.org/pub/firebird/nightly/latest-trunk/Firebird-mac.dmg.gz

...which renders in-line as text-plain on Camino 2003100911.

I recommend resummarizing as an RFE, and have Camino present the user with a
dialog box stating something like:  "The file 'Firebird-mac.dmg.gz' appears to
be a text-plain file.  Would you like to view it in a window, or download it to
your disk?"  [Cancel]  [View]  [Download]


In that case a dialog box stating the problem would be a perfect solution.
This is a tricky area, and the problem has been "fixed" in the past while introducing the opposite 
error, i.e. bug 192410. The dialog should only be triggered if the content doesn't look like what the 
server says it is.

Somebody really needs to propose a MIME type for .dmg files. And then get webmasters the world 
over to actually configure their servers to use it...
For some reason Safari isn't having any difficulties at handeling all the issue
concerning this bug. I realy really wonder how they did this.

The big files are handeled by the download manager even when the content/type is
set wrong and also handles the the html file names .dmg?
Also see Firebird bug 220807.  The proposed Firebird fix is similar to comment
3, above.  The only problem I forsee is the Firebird proposal uses sniffing to
tell the user that text-plain is erroneous.  This appears to violate the
standards, since we should trust the server (to a point).

Conversely, the Camino proposal in comment 3 is to have a dialog stating the
file is indeed text-plain, so the server is trusted, but then give the user an
option other than rendering in the window.

(re comment 6 - Safari is probably sniffing the file and overruling the
content-type sent by the server, like MSIE)
I think  it's great and very progressive to trust servers. But if we know that
80% of the servers world wide are configured badly, why would we want to trust
them? I really think that file sniffing is needed to rule out the problems
Camino and all other Mozilla based users get by trusting servers. 

Generally users just want things to work and they don't care how.
Attached patch patch that'll never be accepted (obsolete) — — Splinter Review 
Hi.  This has bugged me for a long time.  So I fixed it.  The way I chose to
fix it, however, is never going to be acceptible to the powers that be.  Why do
I say this?  Because I've read through the discussion on bug 175848.  In fact,
I stole most of the patch from bug 175848, but rather than declare anything
with a .dmg or	.dmg.gz an octect-stream, I call it unknown content and let the
unknown content sniffer deal with it.  

In case you're concerned, it manages to avoid the bug 192410, too.  

Perhaps somebody else will find it useful in their own private builds.
I realy realy think this should be checked in on the trunk for the reason I gave
in Comment #8.

Camino is rendered useless and will hang by trusting servers. This is not a good
policy by Mozilla. We need a fail save system. Double check if the server is
correct. If it isn't don't make the users live miserable. Deal with the file as
it should be done.
*** Bug 209543 has been marked as a duplicate of this bug. ***
fwiw, the following file does not download with Dave Haas' patch (comment 9)
applied in Haas build 20031018:

ftp://ftp.kensington.com/MAC/Input/mwinstall_2.4b1.dmg.sit
re: comment 12.  That's odd - the link works fine for me with that build.  Plus,
checking with curl, the ftp server isn't sending back a content-type, so the
patch shouldn't come into play . . .
any idea what this will do to pageload performance, now that we're doing more
work on every text/html pageload?

we should run the pageload test on this. chris, are you still in a position to
do that?
related: bug 185222 for WMV on windows, bug 150306 for evangelism.
also related: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13986

In the patch, in the @@ -325,6 +336,8 @@ hunk shouldn't there be a whole lot
more of +'s?

I'm not sure if text/html is required. Smfr said: 'I've seen reports of servers
serving up .dmg.gz as "text/html" too. So maybe it's not just text/plain.' ...
hardly conclusive, and I've never heard of it happening with text/html, can
anyone confirm an actual sighting of that?

is it possible to turn aroound the logic and look for .dmg first and then
text/plain? I think that would generate less hits in the codepath.
Updated patch. I think SubEthaEdit is doing something bad which screws up diff.
 Just a warning.
Attachment #133467 - Attachment is obsolete: true
discussions of what bz (who would be fixing the bug) wants to do are in bug
220807. ignore the ranting about adding a UI picker, they're not gonna do that
in firebird either. 

just wanted to show there was some progress here. i'll keep everyone posted.
dupe of mozilla bug, we should get closure on this in 1.7a

*** This bug has been marked as a duplicate of 220807 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: