Closed Bug 201546 Opened 21 years ago Closed 21 years ago

Can't hide opening dialog if download filetype is application/octet-stream

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: mikus, Assigned: law)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4a) Gecko/20030409
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4a) Gecko/20030409

I have selected not to use Download Manager.  The first time I download a file
with a particular MIME-filetype, Mozilla shows a dialog window asking what it
should do with files of this type.  The dialog window includes a checkbox titled
"Always show this dialog before handling files of this type".  For all other
filetypes in my experience, the default is 'unchecked', and Mozilla honors the
way I leave that checkbox.  For MIME-filetype application/octet-stream, that
checkbox is grayed out (and the default is 'checked').

This means for MIME-filetype application/octet-stream, I can NOT specify whether I
want to hide the dialog window for subsequent downloads of files of this type --
Mozilla ALWAYS shows the dialog window for all downloads of
application/octet-stream files.

Reproducible: Always

Steps to Reproduce:
1.Click on an URL which points to a file having MIME-filetype
application/octet-stream
2.Observe the 'Opening ...' dialog window

Actual Results:  
The "Always show this dialog before handling files of this type" was grayed out
(and had the checkmark set by default).

Expected Results:  
I expected Mozilla would allow me to change the setting of the "Always show this
dialog before handling files of this type" option.
OS: other → OS/2
This is not OS/2 specific. I believe it was done like this for security reasons.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: OS/2 → All
Hardware: PC → All
You can do it if you do it manually via preferences, if you really want (which I
sort of doubt, by the way -- what would you set it to be handled as?).  We do
not let you change it from this dialog, because people were accidentally setting
MIME associations for application/octet-stream and then all sorts of files would
get opened with whatever random helper they had opened the first one with... See
bug 189598 and its dozens of duplicates.

One option here would be to allow unchecking that checkbox, but check it by
default (unlike all other filetypes) and only save the handler & such if the box
is unchecked....  Thoughts on that?
> One option here would be to allow unchecking that checkbox, but
> check it by default (unlike all other filetypes) and only save
> the handler & such if the box is unchecked....  Thoughts on that?

Fine with me.
[Off Topic]

I have a preference for CLI over GUI.  If I could go in with a text editor and
change mimetypes.rdf, I would have no need to write such a bug report.

But all too often the <RDF:Description> tags in that file are __not__ "atomic"
-- that is, they are not each followed by a </RDF:Description> tag -- rather,
there are multiple (apparently unrelated !!) <RDF:Description> tags before a
single </RDF:Description> tag.  I don't understand this, so I don't dare
manually make changes to mimetypes.rdf.  [And yes, I've seen instances where
(after a lot of mimetype entries have been saved to this file) the information
in the Preferences -> Helper Applications panel was inappropriate.  My suspicion
is that the "intermixing" of <RDF:Description> tags was the cause of the
inappropriate values I saw.]
Um.. You can go into the helper app UI and do what you wanted to do.  So I'm not
sure why you'd even need to use a text editor.  That said, are you sure those
description tags were not just empty?

As for "fine by me", I was actually asking pkw for his opinion as to the
technical and user interface merits of the proposal, based on the usage patterns
and bug reports he's seen... I'm really not sure how it helps in your case,
since I still fail to see how the information thus saved would be at all useful
(for one thing, it would store an extension mapping for that type, which you
almost certainly do not want).  Which is why I didn't do it that way originally
and why I'm still reluctant to change it -- it would create UI that would do
something the user does not actually expect it to do....
My feeling is that it is working best as designed. I think allowing the user to 
uncheck the checkbox for types of application/octet-stream will cause several 
people to do things they really don't want to do. Until Mozilla gets some sort 
of ability to sniff the true type of application/octet-stream files, this will 
be necessary.

For advanced users, perhaps we could advertise that they can create a rule for 
application/octet-stream files manually in the preferences - would this be done 
best by adding a note to the release notes?
Not sure a relnote would help -- no one ever reads them...
As per your advice, I used the UI to create an entry for
application/octet-stream.  So far it is doing what I wanted to achieve -- to
*not* have the "Opening ..." dialog window show up every time I download an
application/octet-stream file.

[This means one more UI step every time I install Mozilla from scratch.  As I
said before, I much prefer not to have to use the UI.]

mikus
This also happens for me with video/mpg on Windows 98. Try
http://itsaio.chem.uva.nl/movies/bored_at_work/bored_at_work.mpg for example. Is
this the same bug or a different bug?
The bug I experience is that unchecking the box has no effect. This bug is that
the box is disabled so it's impossible to uncheck, but only with
application/octet-stream. How about changing the summary to something like
"Checkbox to hide opening dialog is disabled if download filetype is
application/octet-stream," which more accurately describes the problem?
Steve, it's disabled on purpose.  As in, it being disabled is not a bug.

Marking this bug invalid, since things are in fact working as designed and no
one has really proposed a workable change to the design.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
*** Bug 315536 has been marked as a duplicate of this bug. ***
(In reply to comment #11)
> Steve, it's disabled on purpose.  As in, it being disabled is not a bug.

The purpose being to harass users.

Its amazing its now 8 years alter and still the problem remains.
So how do we UNDISABLE IT - do we have to hex edit the binaries of FireFail to get it actually save binary files instead of bugging us about it daily???

Pity there aren't microsoft people working on this project, then they could fix it like they have on internet explorer
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.