Closed Bug 201546 Opened 17 years ago Closed 17 years ago
Can't hide opening dialog if download filetype is application/octet-stream
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.
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: 17 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
You need to log in before you can comment on or make changes to this bug.