310468 - Download mgr doesn't handle unregistered filetypes right

Status: RESOLVED INVALID

(SeaMonkey :: Download & File Handling, defect)

Description

[John T]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20050915
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20050915

In the latest Seamonkey nightly and also Mozilla 1.7.12, filetypes not
registered or somehow listed in Mozilla aren't handled right. The bin file in
the URL above is an example, and I have been known to try to download Crafty
chess opening books which are bin files. These files are automatically dumped
into a temp directory and usually lost or deleted. I assigned a read-only
program to open them so they would be saved, but this is a very kludgy workaround.

Mozilla/Seamonkey/Firefox should run all filetypes that aren't known to the
program or the system through the open/save dialog and then the "save as" dialog
so the user gets access to the files he or she is trying to download.

This used to be a capability of Mozilla as I downloaded some bin files a couple
of years ago, but somewhere around 1.5. or 1.6, bin files and similar names were
left out of the dialogs and are still left out.

Some files (txt, jpg, pdf, gif) are opened automatically. Others are known as
files to save (exe, zip). But some files like the bin file in the URL fall
through the cracks. 

Reproducible: Always

Steps to Reproduce:
1. Try to download and save the file in the example URL
2.
3.

Actual Results:  
The file is automatically downloaded into a system temp directory, and then
Mozilla or Seamonkey attempts to open it and there's no default program to open
that filetype. I think Mozilla/Seamonkey then deletes the file as it couldn't be
opened. My work-around to open it with a read-only program lets it be saved, but
that work-around shouldn't be needed.

Expected Results:  
Mozilla/Seamonkey should have shown the open/save dialog box and then the "save
as" dialog box to let the user specify what to do with the file.



This can be a data loss problem, a real bug, so this isn't just an enhancement
request. It's also been noted in previous reports on downloading.

Comment 1

[Pavel Cvrcek [:JasnaPaka]]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050930 SeaMonkey/1.1a

I haven't got a problem with it. All works fine for me.

Comment 2

[John T]

Are you saying you can download the bin file in the example url and you get the
open/save and save-as dialogs?

Comment 3

[Pavel Cvrcek [:JasnaPaka]]

(In reply to comment #2)
> Are you saying you can download the bin file in the example url and you get the
> open/save and save-as dialogs?

Yes. I have tried it on Windows 98 (SeaMonkey 1.1a) and Windows XP (SeaMonkey 1.0a).

Comment 4

[John T]

Interesting. I just tried downloading a bin using Mozilla/5.0 (Windows; U;
Win98; en-US; rv:1.9a1) Gecko/20051004 SeaMonkey/1.1a. I didn't get the
open/save or save-as dialogs, only the download manager window showing progress.
When I clicked on "cancel", the download was marked as finished with the size of
the complete file indicated, though the download had barely begun.

Comment 5

[John T]

It was a small file and the Seamonkey build was pushing kernel usage to 100%.
The download seems ok, but the kernel hogging made the program almost unusable.
Test again after the kernel usage is back to normal.

Comment 6

[OstGote!]

(In reply to comment #2)
> Are you saying you can download the bin file in the example url and you get the
> open/save and save-as dialogs?

Same for me with Mozilla 1.7.12 and SeaMonkey branch & trunk builds on WinXP.
The file type is not registered (type "application/octet-stream"). Please check
your settings, if you have set up any non-working app for that mime type or that
you have a default action to "open" such files (which is wrong).

Comment 7

[John T]

My preferences\helper-apps for octet-stream say that the filetypes are jpg and
jpeg, and the action is to open them with the default application.

Comment 8

[OstGote!]

(In reply to comment #7)
> My preferences\helper-apps for octet-stream say that the filetypes are jpg and
> jpeg, and the action is to open them with the default application.

That is wrong. Change that entry to "Save it to disk" and remove any extension.
Or simply delete it.

Comment 9

[John T]

I deleted the entry for octet-stream, and downloaded a bin file almost ok. The
dialog said the filetype wasn't know and presented the dialogs, but the
open/save box had the "Always do this with this filetype" checkbox shaded out.
Is there any special reason why the action shouldn't settable?

Comment 10

[John T]

This comment applies to the 20051012 win32 build. 

Comment 11

[John T]

Deleting the octet-stream type makes Mozilla stupid. I tried to open a PDF file
received by email and Mozilla recognized that it was a filetype to open with
Adobe Acrobat Reader, but didn't do it until I told it to. And when it did, the
usual Reader menu that lets one zoom in or out and SAVE the file to a desired
location was not available.

What is the problem with handling files according to the filetype indicated by
the extension, instead of calling almost everything "octet-stream" and then
acting dumb?

Bin files are not registered filetypes and so should go through the open/save
and save-as dialogs, but registered filetypes should be handled correctly.
Mozilla still opens jpg files correctly, so why can't it handle pdfs as before
while doing the right thing with a bin file?

Comment 12

[John T]

Answer: It appears that the security settings on the PDF file prevented the normal Adobe Reader menus from appearing.

It also appears that some previous version or action that associated octet-stream with filetypes on my system was the cause of problems downloading various filetypes. I'm not seeing any filetype problems in connection with downloads at present.

Comment 13

[John T]

The discussion in bug #81983 seems to suggest that the octet-stream helper problem may have originated with settings from Mozilla 1.6. 

Comment 14

[Alexander Rabtchevich]

Take a look at the bug
https://bugzilla.mozilla.org/show_bug.cgi?id=313371
I think they are connected somehow.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Sounds like everything was acting "right" given the application/octet-stream settings reporter had.

Issues with particular sites labeling everything as octet-stream should be taken up with said sites.