81418 - file with mime type "application/x-msdownload" not handled properly, and "save to disk" doesn't write file

Status: VERIFIED DUPLICATE of bug 46655

(SeaMonkey :: UI Design, defect)

Description

[Nick Stenz]

I just attempted to download Realplayer 8 basic (minimum install) from
RealNetworks' web site. When I click the link to download, I get the 'What
should Mozilla do with this file?' dialog mentioned in bug 88190.

If I try to set the 'default action', I can't, because it's an executable-
there's no 'save to disk' action, and I'm not going to run the program from
another program. If I pick 'save this file to disk', choose my Desktop, and hit
Save, the file appears to download. However, the file never shows up on my
desktop. A full-disk search for rp8-setup.exe turns up 0 results. It appears
that Mozilla is downloading the data but never creating the file.

The 4.7 MB download took a little under a minute over our T1- so it appears the
data is actually being downloaded; it's just never written to disk.

I didn't try 'Open with application...' either- again, because it's an .exe.

Expected result: 'application/x-msdownload' mime type should be handled just
like any other application. I tested it in IE just to be sure- It worked fine.

Since the MIME type is being returned by the server, I should probably write
down that I keep picking the middle SF Bay Area server (205.158.58.128 is
referenced in the middle of the redirector's URL).

Comment 1

[Nick Stenz]

Blah... I should've used the helper. Forgot the build.

Build ID: 2001050915 (Windows 98)

Comment 2

[Mark Heily]

There are 2 parts to this report:

#1)

There is no intutitive way to run an executable (see Bug 42015) although the
functionality exists. Selecting "Open With" for an executable will run the file,
however.

#2) The problem with Mozilla not saving a file to disk. I could NOT reproduce
this under Mozilla.9/Win98. 

Reporter- There is no bug 88190 in the database, was that a typo?

Recommendation:  Change bug status to CLOSED, WORKSFORME

Comment 3

[Mark Heily]

I also just noticed that the MIME type for the file (as it is returned by the SF
Bay server) is "application/octet-stream" and not "application/x-msdownload" .

Comment 4

[timeless]

reporter if you want to find out what happened to the file, visit 
http://www.sysinternals.com/ and get filemon.exe then run it as you use 
mozilla, specifically monitor only mozilla and probably only the cache and temp 
directories.

[e-mail] closed is not a status we use often.  the two standard onces are 
Resolved and Verified.

The fact that you two got _different_ mime types is interesting.  I'm sending 
this to networking:file.  Someone from networking:http should see if different 
servers are really giving different mime types.

Comment 5

[Nick Stenz]

I didn't actually check what the server returned myself- Mozilla 
said 'application/x-msdownload'. If it's returning octet-stream, good... 
However, that's not what Mozilla told me.

Also, that bug # I was referring to was bug 81190. Sorry. I bet it will make a 
bit more sense now.

Comment 6

[Boris Zbarsky [:bzbarsky]]

The dialog probably lied to you about the file type.  It does that for unknown
file types (and application/octet-stream).

So the file is probably served as octet-stream from both places.

Comment 7

[basic]

reporter: do you still see this bug in the latest build?
with build 2001061804 win32 this works for me. Though I can't find your bay area
link. Could you test with another site? Another possibility is that something in
your windows registry is causing this. Could you goto HKEY_CLASSES_ROOT\.exe in
your registry and tell me what you see?

Comment 8

[basic]

After more testing it seems that application/octet-stream might not be handled
properly on the reporter's machine. If it is still a problem on your machine I
would suggest in pref->navigator->Helper Application
create a new entry with

Description of type:
File extension:
MIME type: application/octet-stream
Application to use:

click OK

click on application/octet-stream
click Edit
select Save to Disk
uncheck the "Ask me before opening downloaded files of this type"
click OK

Sometimes I wonder if Mozilla should have this entry there by default

Comment 9

[Nick Stenz]

I see that Mozilla is handling application/octet-stream as an unknown type and 
checking the registry, where it gets the application/x-msdownload mime type 
from. Normally I would say the way Mozilla behaved was correct- however, I 
agree with [e-mail]. application/octet-stream should be registered 
as 'save to disk', with an option of 'open with ...'. Everything would be just 
fine if Mozilla would actually write the file to disk. I just grabbed a build 
from 06/13, and it appears to work properly now. Changing resolution to fixed. 
(Am I supposed to do that on a bug marked unconfirmed?) However- the SF bay 
area servers I was using for downloads are no longer listed on that page. Are 
the WA servers also returning application/octet-stream? I'm at work and don't 
really have time to check right now. =|

For anyone that didn't have trouble with this:
1) do you have application/octet-stream configured in your Mozilla prefs? (I 
don't.)
2) what's in your HKEY_CLASSES_ROOT\.exe?

Just curious...

Comment 10

[basic]

reopening bug to mark as duplicate

Comment 11

[basic]

*** This bug has been marked as a duplicate of 46655 ***

Comment 12

[timeless]

it'd be nice if software didn't lie wouldn't it... verify dupe

Comment 13

[benc]

->xp apps