240230 - "Opening <filename>" dialog box does not allow user to choose "Do this automatically for files like this from now on."

Status: RESOLVED DUPLICATE of bug 315536

(Toolkit :: Downloads API, defect)

Description

[Michael]

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.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

>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

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

(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)

Comment 3

[Ali Ebrahim]

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

Comment 4

[Jared Thomas]

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.

Comment 5

[Jared Thomas]

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.

Comment 6

[Ali Ebrahim]

(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. :)

Comment 7

[Phil Ringnalda (:philor)]

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

Comment 8

[Jared Thomas]

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

Comment 9

[Michael]

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.)

Comment 10

[Krishna Sethuraman]

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?

Comment 11

[Krishna Sethuraman]

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.

Comment 12

[Mike Kaply [:mkaply]]

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.

Comment 13

[Brendan Eich [:brendan]]

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

/be

Comment 14

[Phil Ringnalda (:philor)]

(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 ***