User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Mozilla does not appear to have a good way to ADD file handlers for new file types, though you can REMOVE them through Options -> Downloads. There is no way to add a new file handler in Options -> Downloads. If you hit a new file type, you get a dialog box asking you what to do with the file. The dialog box allows you to choose a handler or save to disk. But the check box that says ""Do this automatically for files like this from now on." remains greyed out regardless of what you select, so you can not use the dialog to add a new file handler, or assign the same one to repeatedly handle the same file type. Reproducible: Always Steps to Reproduce: 1. Create a binary file with an extension not used by a file type that Firefox knows about. (I chose .qzy) 2. Attempt to download the file using firefox. 3. Either select "open with" in the dialog box (and choose a file handler), or select save to disk. The "Do this automatically for files like this from now on." checkbox remains greyed out. 4. Attempt to open the file again. The choice of handler or save to is not preserved. Actual Results: I was asked every time what to do with the file. Expected Results: The "Do this automatically for files like this from now on." checkbox should be selectable. Choices of file handler should be preserved. There should be an "add" button in Options -> Downloads that allows you to add new file handlers.

>Mozilla does not appear to have a good way to ADD file handlers for new file >types, though you can REMOVE them through Options -> Downloads. please don't file firefox bugs in the browser product, thanks

(In reply to comment #1) > please don't file firefox bugs in the browser product, thanks (that should've been "firefox-specific bugs". mozilla does allow you to add file handlers)

I see this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040428 Firefox/0.8.0+. --> NEW

The check box "Do this automatically for files like this from now on." is no longer greyed out on release 0.8, however checking it has no effect. Every time a given filetype is encountered, the "Downloading <filename>" window still appears. In my case, I am following a link which goes to a PHP generated page which contains a graphic (gif or jpeg). A blank page (window or tab) is displayed and the "Downloading <filename>" window appears, correctly primed to open (not download) the graphic. Clicking "OK" displays the graphic in my Windows assigned viewing program. The blank window (or tab), which should display the graphic, remains open and mut be closed manually. This behavior has been reported by at least 3 people in the forums.

I apologize; reading the fine print, this report is written against Mozilla and I am reporting a Firefox problem. I will continue looking for a Firefox bug report to post this to. Sorry to bother the Mozilla developers.

(In reply to comment #5) > I apologize; reading the fine print, this report is written against Mozilla and > I am reporting a Firefox problem. I will continue looking for a Firefox bug > report to post this to. Sorry to bother the Mozilla developers. No, you're in the right place. This bug is to do with Firefox Downloading. :)

Is anyone still seeing this, when the file is sent with a new-to-Firefox mime-type? If I send good.cheese with Content-type: application/x-cheese, I get to choose a handler and check the box, and then stinky.cheese with the same content type header gets automatically sent to the same handler. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

This problem did not go away when I updated to Firefox 0.9.3.

The bug still occurs in Firefox 1.0PR. (By the way, should replying to a bug e-mail result in a post on the bug webpage? My reply by mail does not seem to have posted.)

I'm running into this on a Mac as well. 'Preview' comes preinstalled on all Mac systems, and is a good candidate for default PDF viewer in preferences->downloads->file types. As it is, there's no entry at all in the file types listing for application/pdf (or whatever the mime type for PDF is). Hence, I can't re/assign a pdf viewer for this item myself. I'm willing to go with a workaround for now. Is there a workaround for this on the Mac?

Whoops, ignore that. application/pdf does show up in the file type list (in a pristine profile), and I can change it in the same way on the mac as I do under NT.

I seem to have found a workaround for this. If you go into options and delete it than get the dialog again and check the checkbox, it seems to stick.

Is this fixed now, or is bug 315536 a dup of some sort? /be

(In reply to comment #13) > Is this fixed now, or is bug 315536 a dup of some sort? Who knows? There's not a URL anywhere to see what it was talking about. The comment 7 case remains fixed (and I wondered why I had those .cheese files in my testcase directory). The comment 4 case is almost certainly sent with Content-disposition: attachment, so it's either bug 285976 to not pretend you can choose automatic handling, or bug 236541 to let you choose automatic saving-only. The comment 0 case, while talking about a handler UI, would have been producing Content-type:application/octet-stream, which we do not want to allow handlers for because of all the reasons in bug 189598 and its duplicates, so the only options are "don't pretend you can choose to have this remembered" or "automatically download binaries with no user intervention if they've also chosen to not have the filepicker come up" which is bug 315536. Duping forward, since that one's actively owned and more focused. *** This bug has been marked as a duplicate of 315536 ***