User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040304 Firefox/0.8.0+ (BlueFyre) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040304 Firefox/0.8.0+ (BlueFyre) I haven't yet figured out what causes this bug on some files and not others, but sometimes the "do this automatically for files like this" checkbox doesn't work. It happens for me repeatably at: http://media.ebaumsworld.com/index.php?e=homebase.asf No matter how many times I download the file and check the box, Firefox still asks me what to do with it. Reproducible: Always Steps to Reproduce:

I can't reproduce this. It seems to work fine for me whether I choose to always save, or always open. I'm using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040302 Can you try to reproduce this using the latest OFFICIAL build, available from here: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Also, please remember that when you install a new build, you need to delete the old install first so you install in an empty folder. Also, please test using a clean profile. To do this, delete or move away %AppData%\Phoenix. Let us know how this works out for you.

Correction: The UA I tested with in comment 1 is actually the following: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040302 Firefox/0.8.0+

Still happens for me at the given URL with latest official installer build and brand spanking new profile. Perhaps it has something to do with my file associations for .asf files?

Perhaps, are you using Windows Media Player 9 to view your ASF files by default? Also, can you try it with the latest non-installer build? ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-03-02-08-trunk/Firefox-win32.zip Just extract this into an empty directory.

Still happens with that build and a new profile. Actually I'm using Winamp to view .asf files, but the dialog shows the windows media player icon for some reason (see above screenshot). In Explorer .asf files show up with a Winamp icon, have the filetype "Winamp Media File," open in Winamp on a double-click, and have "Play in Winamp" as the default action.

One more thing to try. When you choose do this automatically for all files like this, pull down the drop down menu next to open with, and browse to the winamp.exe file, and see if it remembers that. Also, go to Tools | Options | Downloads and see if the appropriate entry is there. I forgot to ask earlier, are you seeing this behaviour only on this file type, only on this URL, or on many file types or URLs. Even before, was there an entry made in Tools | Options | Downloads relating to how to download ASF files? Also, if anyone else is out there reading this, can you reproduce this?

I notice that http://media.ebaumsworld.com/homebase.asf is served as text/plain, so perhaps that is causing the problem (though it's hard to say for sure without more links).

OK, I've done some more testing at http://www.collegehumor.com/?pg=movies . I think the problem is in the default file actions that Firefox detects somehow when it first runs. Here's a picture of the download options dialog after first starting on a new profile. Some of those associations work fine (MPEG for example), but some seem to be corrupted. WMV files have the same problem as I described for ASF files above, even though they have an entry in the list saying "Open With Winamp". As you can see, ASF files don't have an entry in the filetype action list. For AVI files (which have an entry saying "Open With Winamp"), Firefox behaves as if they don't have an entry in the list yet. After using the "do this automatically for files like this" checkbox on an AVI file, another entry for AVI files is put in the list (so there are two entries for the AVI file type). If I delete all of these filetype actions, then everything seems to operate as it should, with the "do this automatically for files like this" checkbox working as intended in every case (even ASF).

Confirming bug on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040302 Firefox/0.8.0+ It appears that in this case, the ASX/ASF entry is a shared one (and that there is a problem with it). If you delete the default one that Firefox creates (leaving all the others there), it works okay. This may just be a more general problem of that affects things where you don't use the default file handler. --> NEW

I'm not sure why Firefox decided that I want to open all those files in Winamp anyway. I don't. I don't want to open Word documents in Word either. I just want everything to be downloaded so I can know exactly where it is and then open it myself. If Firefox didn't provide these default "open in foo" actions, that would fix this problem.

*** Bug 242634 has been marked as a duplicate of this bug. ***

The common thread between this bug and bug 242364 is that both of them are experiencing this problem when the files are served via a PHP script. Updating summary.

In my list of file types under Tools / Options / Download there are no visable duplicates. I mention this because the original reporter found some and deleting them seemed to help.

Further (and not directly related to this report) the page being created by the PHP server intends for the graphic to be displayed on the page, not handled by download manager. A blank window/tab is opened; download manager started, and the blank window/tab must be closed by hand. This may not be relevant... Should an examination of the stream being provided by the PHP server be needed, I can do a line trace to capture it.

Comment #7 asked for more users.. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040519 Firefox/0.8.0+ Clean install, using the CollegeHumor.com URL from comment #9. I click on an AVI file, get the Open/Save dialog, click on Save and "do this automatically". The next time I click on an AVI file the D/L starts to a temporary file and afterwards opens the file. Wrong. The Tools - Options - Downloads entry for AVI is "Open with BSPlayer". Wrong. Regarding comment #13 - I don't think it's a PHP server. My test case was this URL: http://content.collegehumor.com/media/movies/rapidfirecansmash.avi

I'm running FF 0.9rc 20040614 and I've been having this same problem with WMV files. As per a previous suggestion, I deleted the existing entry for WMV in the Download Manager options and FF now remembers the setting.

Once again, I'll say that this problem is caused (at least in some cases) by the default actions Firefox creates when installed. There are several reasons why these actions are bad: 1. They're broken and they cause this bug. 2. They aren't what many users want. I don't know about you, but the first thing I do nowadays when installing Firefox is go into the download options and remove all the default "open in _____" actions for things like word documents, powerpoint files, MP3s, and video files. These are always created even when installing from scratch with a blank profile. 3. They turn any exploit in these programs into an instant remote hole in Firefox. For example, if a code execution hole is found in Winamp's MP3 reader (it's happened before), that instantly becomes a one-click exploit for Firefox, since at least on my computer Firefox opens MP3s in Winamp with *one click* and *no warnings* by default. This is a SERIOUS security problem that needs to be fixed before 1.0; preferrably ASAP. It can be fixed by simply removing these default download actions.

Got the same problem with pdfs. I opened it from a https-site (maybe it has to do with that?)

I'm able to duplicate this bug. Visit http://www.emusic.com (you don't have to be a member), and try to preview songs. It'll prompt you with the "You have chosen to open" dialog every time you click one of the m3u links. As requested in one of the posts here, I've verified that M3U is in tools->options->downloads. It's set up to automatically open files with M3U extensions with the default application "m3ufile". There is no indication that the server is running PHP, and it's not being accessed via HTTPS. "Trying 64.124.6.60... Connected to www.emusic.com. Escape character is '^]'. HEAD /m3u/song/10844133/13120918.m3u HTTP/1.0 Host: www.emusic.com HTTP/1.1 200 OK Date: Mon, 10 Jan 2005 02:50:46 GMT Server: Apache/1.3.29 Ben-SSL/1.53 (Unix) mod_jk/1.2.0 Expires: Mon Jan 10 21:50:48 EST 2005 Cache-Control: Content-Disposition: 13120918.m3u Content-Length: 0 Connection: close Content-Type: audio/x-mpegurl" I'm running: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0"

I see this exact thing when downloading my financial statement into Quicken. On one of my banks sites(https://www.atbfinancialonline.com/) the file automaticlly launches and opens quicken, on the other(https://www.cibconline.cibc.com/bvtrx01/script-root-tran/accounts/TransactionDownload2.cibc) the dialog to open the file or save it comes up everytime. The option to "do this automaticlly" is checked already when the dialog box comes up. This should demonstrate that the setting is correctly set in firefox its something about how firefox gets the file from the two different sites. If someone would like some actually raw http headers or something i would be happy to grab that info, but i'm not sure what you would want. Let me know.

I believe this bug has to do with servers that send Content-Disposition headers. I see this problem with bittorrent sites. On some, the torrent is automatically downloaded and launched in Azuereus, my configured handler for torrent files. On other sites, I get the "What do you want to do with this file" dialog box. I wrote a simple script which helped me reproduce it: <?PHP $filename = "test.torrent"; $fn = $filename; header("Content-Length: " . filesize($fn)); header("Content-Transfer-Encoding: binary"); //header("Content-Disposition: attachment; filename=\"" . $filename . "\";"); header("Content-Type: application/x-bittorrent"); header("Transfer-Encoding: chunked"); @readfile($fn); ?> If I uncomment the Content-Disposition header, I receive the dialog prompt. Otherwise, as is, the file gets downloaded automatically. Does anyone know if there's something in the RFC about Content-Disposition which mandates that the user should be prompted? If this is indeed the distinguishing characteristic that causes the dialog prompt, is it really a bug? I'd personally like for the "Always do this" option to do what it says.

According to the Content-Disposition RFC http://www.faqs.org/rfcs/rfc2183.html 2.2 The Attachment Disposition Type Bodyparts can be designated `attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user. The MUA might instead present the user of a bitmap terminal with an iconic representation of the attachments, or, on character terminals, with a list of attachments from which the user could select for viewing or storage. This makes it sound like Firefox is doing the technically correct thing. So, I'd like to suggest a setting that would allow users to indicate that attachments should also be handled automatically. Or would this be better as an extension?

The text "their display should not be automatic, but contingent upon some further action of the user" is intended to differentiate email bodies from email attachments. Since Firefox isn't a mailer, the exact text of the RFC can hardly apply literally. If Firefox is set for automatic downloads, it isn't even violating this section since it doesn't display the attachment automatically. Instead it follows the RFC by presenting "the user of a bitmap terminal with an iconic representation of the attachments" in the download manager which is fine. Even if Firefox is set to automatically launch files, it still brings up the download manager, which allows the user to save the file in a different location. What this RFC intended to prohibit was displaing the file inline in the Firefox window (like, say, in the PDF plugin).

OK, I give up. I've spent over two hours investigating this, trying different combinations of mimetypes, content-distribution headers, and file extensions. I have figured out that if content-distribution:attachment is used, the dialog always shows up. I think it shouldn't if you've set auto-downloading. So this bug is valid the way it is and should be easily fixable. However, in all other cases (when the mimetype is application/octet-stream, text/plain, or an unknown mimetype), Firefox's behavior is totally inconsistent, even when it guesses the filetype correctly. Sometimes the auto-download checkbox is disabled (though sometimes a previously set auto-download preference will still work on these files, and sometimes not), sometimes the checkbox is enabled but it doesn't work (though I've run into this in the wild I can't reproduce it now), sometimes the same file served with a different mimetype will have separate auto-download settings (so the same file extension is listed twice in the options dialog), but sometimes not. Which problems happen seems to depend on how your file associations are set up in Windows, and also which filetypes you have set to auto-download already, through some complex mechanism I haven't figured out. I think further investigation can only be done by someone looking at the actual code.

FWIW, through no action of my own, save for upgrading to Firefox 1.0.1, my test case with eMusic is no longer valid. That is, it is working as it should be. There are still other what I would consider "major" flaws in how it handles it, but I'll save that for another bug report.

The "Do this automatically for files like this from now on." implies that the dialog box should not appear. I have this same problem when clicking on attachments in Yahoo webmail where the 'sending' email client does not properly inline the attachment as image/jpeg. Email tests to my yahoo account with an attached JPEG, from AOL webmail, Eudora, Gmail, Hotmail, and Outlook XP all produce the dialog box before opening. I have the settings set to open JPEGs in Firefox. Email tests to a yahoo account with an attached JPEG from Yahoo Webmail or from the [great] Thunderbird do properly inline the attachment as image/jpeg and when clicking on the attachment in yahoo webmail, the image opens in a new Firefox window. (no dialog box)

I do not think this is a bug. FireFox is doing exactly what the RFC for "Content-Disposition" says to do when the disposition type is "attachment". See the RFC: http://www.faqs.org/rfcs/rfc2183.html From the RFC for disposition types of "attachment" it says: 2.2 The Attachment Disposition Type Bodyparts can be designated `attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user. The MUA might instead present the user of a bitmap terminal with an iconic representation of the attachments, or, on character terminals, with a list of attachments from which the user could select for viewing or storage. Note, that line that says: "display should not be automatic, but contingent upon some further action of the user." I believe that FF should give the user some indication of why it is not following the user's requested action. For developers: I developed an application that was using the "Content- Disposition:attachment;filename=..." and I was having problems. I switched my "Contenet-Disposition" header to replace the word "attachment" to "inline" and this solved my problems. Here is what the RFC says about the disposition type "inline": 2.1 The Inline Disposition Type A bodypart should be marked `inline' if it is intended to be displayed automatically upon display of the message. Inline bodyparts should be presented in the order in which they occur, subject to the normal semantics of multipart messages. So I think the problem is that FF is doing what the RFC says to do, but it is not telling the user why it is not following the users specified instructions.

As an end user, this would just further my frustration: a computer program telling me "I'm ignoring your preferences in favor of some random webmaster's preferences" -- Might as well be using Internet Explorer. :-) A compromise might be to have an option that the user can set, that would allow the browser to ignore RFC2183 2.2.

(In reply to comment #29) > I do not think this is a bug. > [...] > See the RFC I disagree very strongly. I have already explained why this exact section of this RFC does not prohibit Firefox's automatic downloads. Let me repeat myself: The RFC states that *display* of the attachments should not be automatic, but that the program should present the user with a *list of icons* representing the attachments. The download manager fits that description perfectly, as it does not display the files but merely icons. To display the files, the user must take the "further action" of double-clicking, exactly as described in the RFC. The RFC says nothing about whether or not the file should be downloaded, but this is probably because it is talking about *mail clients*. Since Firefox isn't a mailer, the exact wording of the RFC can hardly apply. The fact that Firefox automatically begins downloading the files could simply be seen as a highly effective pre-emptive caching strategy :-)

I am observing this on Debian bug reports, e.g. the log files attached to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320627&msg=32 RFCs are all well and good, but being forced to use an external program to view a text file really is rather silly.

To reiterate: Even if we feel the need to follow the RFC, the "further action of the user" was specified earlier, when the user chose to "do this automatically for files like this". This basically means that prompting for further action is unnecessary and unwanted by the user.

Since blocking 1.5 flags are not being used anymore, blocking1.8b4 flag needs to be set so bug does not fall off the radar if someone changed their query and miss these bugs with blocking 1.5 flags still in place and no blocking 1.8b4 flag set. So a sufficiently empowered user needs to remove the blocking1.5+ flag and change the blocking1.8b4 to +

This bug, as summarized, is invalid, per comment 29 and others. The fix in this case is to grey out the checkbox when Content-Disposition: attachment is used, and that's bug 285976.

(In reply to comment #35) > This bug, as summarized, is invalid, per comment 29 and others. The fix in this > case is to grey out the checkbox when Content-Disposition: attachment is used, > and that's bug 285976. Enough people have pointed out that firefox's behavior is correct according to the RFC, but enough people have also pointed out that its very irritating. Invalidating this bug and/or making the "Remember this" checkbox readonly will not, in my opinion, do anything to *enhance* the user's experience but will keep things frustrating. What are we users who hate this behavior supposed to do? Petition to change the RFC? If we're not going to "fix" this bug, is there anyway for those of us who what the behavior changed to get our wish? Would an extension solve this?

(In reply to comment #35) > This bug, as summarized, is invalid, per comment 29 and others This bug is valid, as I have explained twice already in comment 31 and comment 24, directly addressing the issues brought up in comment 29 and others. Do you disagree with my argument?

So there are two issues here. 1) UI bug. If the "do this automatically" checkbox setting for a file will just be ignored, then it should be disabled or not even present. Seamonkey gets this right, for example. This seems to be covered by bug 285976. 2) Correct general behavior. The key is that for content-disposition:attachment silent handling of data by the browser, a plugin, or a helper application is not acceptable. The former two cases are handled by not even trying to handle that way. The last case is handled by forcing the helper app dialog to come up even if the "don't show the dialog" preference is set. Perhaps what we should do instead for #2 is to force the dialog up if any action other than "save as" is selected. If the user has chosen to save some sort of data, then it should be fine to just silently do that for content-disposition:attachment. Combined with fixing bug 285976, that should address the issues this bug was filed on, I think. biesi, thoughts? I believe this would take nsExternalHelperAppService changes, so perhaps we should move this bug to core.

(In reply to comment #38) Thank you for understanding the issue. It would be great if your fix for 2) was implemented. But I still believe Firefox should honor the user's request in all situations, even when it might mean deviating slightly from the RFC. My reasons are: 1. The wording of the RFC is for 1997-era mail programs, not cutting-edge web broswers. 2. There is precedent; some mailers also ignore the RFC to display image attachments inline. 3. We are only ignoring the RFC at the explicit request of the user (and all we are ignoring is the RFC's request for user input anyway). 4. The change has zero disadvantages; compatibility with all websites is unaffected, there are no security problems, and users are uniformly happier.

> 4. The change has zero disadvantages; compatibility with all websites is > unaffected, Actually, this is the point. Compatibility _is_ affected. Consider a multipart/x-mixed-replace document with a part that is content-disposition:attachment and isn't the last part (this is UI that appears in several government document management systems; the attachment part is typically the document in question as a PDF, while the other parts are some sort of "waiting" and "document generation done" text). If we handle the attachment inline in this case the user will simply never see it, since the following part will immediately replace it. There are also some other cases where the intent of the website is to allow the user to save something and showing the data in a helper app would actually make that impossible (some viewers have no "save as" functionality, since they don't support editing). All of this is easy to figure out by looking at the bugs that caused the current code to be written the way it is, so I have to wonder where this "compatibility with all websites is unaffected" idea came from.

(In reply to comment #40) I fail to see how this change would make Firefox incompatible. Nobody is suggesting displaying the attachment inline in any situation and multipart/x-mixed-replace does not change that; the attachment will always either be downloaded or downloaded and then opened in a helper application, so it has no chance of being overwritten by new content in the Firefox window. Furthermore, it will *always* appear in the download manager even when opened in a helper application, so users can access the file after it is downloaded regardless of whether the helper application has "save as" functionality.

> Furthermore, it will *always* appear in the download manager We're talking about a core change, so the details of the Firefox UI are irrelevant here. There are apps other than Firefox using this code.

(In reply to comment #42) > the details of the Firefox UI are irrelevant here. The details of the Firefox UI *are* the bug. Are you saying it's impossible to change this in Firefox's UI without a core change that will automatically affect every other application? Surely there is a way to fix this in a less invasive manner. What problems in particular are you worried about causing?

> Are you saying it's impossible to change this in Firefox's UI without a core > change Yes. See comment 38. > Surely there is a way to fix this in a less invasive manner. Not as things stand. The decision on whether to pose the dialog is made in core code, and the actual execution of the chosen action is performed there as well. The app merely provides the implementation of the dialog.

I'm not sure that's true, couldn't nsIHelperAppLauncherDialog::show directly call the methods on the nsIHelperAppLauncher, without showing the dialog?

Possibly it _could_, but I think that would be violating the contract for some of the dialog reasons (and we should document that).

If so, perhaps the contract should be changed. Alternatively, wouldn't it be possible to change the core in such a way that the new behavior happens only when an option is set, preventing other applications from being affected? (as I was trying unsucessfully to get at in the part of my question omitted from your reply) In any case, if still you believe enabling automatic helper apps for attachments is wrong or infeasible, I will be happy if only automatic downloads are enabled for attachements, as you originally proposed. I don't often use automatic helper applications anyway.

Changing the contract also affects all apps using it, but perhaps it could be done in a way that allows reasonable flexibility thereafter. Helpwanted on that if someone can come up with the code. I'd really rather not have two completely separate core codepaths here (the "option is set" thing), though.

*** Bug 267479 has been marked as a duplicate of this bug. ***

*** Bug 269147 has been marked as a duplicate of this bug. ***

*** Bug 276262 has been marked as a duplicate of this bug. ***

*** Bug 309013 has been marked as a duplicate of this bug. ***

(In reply to comment #52) > *** Bug 309013 has been marked as a duplicate of this bug. *** well im dumb, and made a dupe bug. My two cents is that when a checkbox that is equivalent to "dont show me this again" is checked, it should never show up again with out going through some config screen or file.

*** Bug 311470 has been marked as a duplicate of this bug. ***

*** Bug 312528 has been marked as a duplicate of this bug. ***

Re-installing Mozilla will "sometimes" correct this bug, IF Firefox is completely uninstalled first AND all files that are associated Firefox are deleted. (Running CCleaner to remove any lingering registry issues may also help.) However, this fix apparently does not resolve this particular bug on all computers. (I have two computers and re-installing worked on one but not the other. Both computers run on Windows2000 operating systems.)

(In reply to comment #56) > Re-installing Mozilla will "sometimes" correct this bug If that's true, you're not seeing this bug.

(In reply to comment #57) > (In reply to comment #56) > > Re-installing Mozilla will "sometimes" correct this bug > > If that's true, you're not seeing this bug. Actually, I am seeing this bug (or had previously seen it) which is why I reported it to Bugzilla in the first place. The bug affected Word and Adobe PDF files, which refused to open automatically by double clicking on them -- even when all the appropriate boxes were checked. It may have also affected other file types, but these are the ones I generally open from web sites. In one of the Bugzilla threads, someone suggested that the problem could be fixed by completely un-installing Firefox, deleting all associated files, and then re-installing it. I tried that, and behold it corrected the problem on my computer at home (Word and PDF files now open automatically) but the same "fix" had no effect at all on the computer I use at work. I am not making this up.

(In reply to comment #58) > I tried that, and behold it corrected the problem on my > computer at home (Word and PDF files now open automatically) but the same "fix" > had no effect at all on the computer I use at work. I am not making this up. I'm not accusing you of making it up, I'm simply pointing out that your issue is a different bug, not this one. This bug is about Firefox ignoring "do this automatically" for files sent with content-disposition: attachment, as stated in the summary.

*** Bug 313130 has been marked as a duplicate of this bug. ***

*** Bug 313140 has been marked as a duplicate of this bug. ***

*** Bug 313152 has been marked as a duplicate of this bug. ***

*** Bug 314304 has been marked as a duplicate of this bug. ***

I have a PHP script that creates a plain .txt file and sends these headers: Content-Type: application/force-download Content-Type: application/octet-stream Content-Type: application/download Content-disposition: attachment; filename=file.txt And the Open dialog still shows up even after I click "Do this automatically...". I'm using Firefox 1.5 RC 1 on OS X.

Is this bug in the right product and component? If so, to whom should it be assigned? /be

the component is right, the product probably is as well, firefox should just disable the checkbox in this dialog, like seamonkey does (in the cases where it doesn't work). although if comment 38's issue 2 is to be solved in the proposed way, then this does belong into core...

Bug 285976 handle's disabling the checkbox, so I think this bug should probably be morphed to address comment 38 issue #2.

(In reply to comment #67) > Bug 285976 handle's disabling the checkbox, so I think this bug should probably > be morphed to address comment 38 issue #2. Agreed. Biesi, if you agree, can you reassign and otherwise fix up this bug's fields? I bet bz will have something to say when he's back after the holidays, but it would be good to get this bug moved to Core right now. Thanks, /be

Hello. I was referred to this bug by someone who believes that this bug describes what I am experiencing. So hopefully this will help. I had seen this bug go away in some of the prior releases of Firefox (1.0-1.07), I think), but it seems to be back now. Starting in 1.5, if I try to download a file of type wmv, Firefox asks me what I want to do with the file, and ignores my preference to open it in Windows Media Player. Other file types are handled properly. So something has changed in the latest version of Firefox that has reintroduced the bug, at least on my system.

This BUG show just how out of touch with reality Firefox's developers are. Who gives a rat's ass about whether the program is following some protocol properly or not. To the end user it is not doing what it has been told to do and is therefore a bug. It's this kind of attitude that keeps Firefox from becoming a mainstream product. If it doesn't perform the way the end use wants it to then people are going to use something else. I can confirm that the "Do this automatically..." check box has never done anything on any of the computers I have used Firefox on. So what is the point of having an option in the program that is ignored because the developers think following a protocol is more important than doing what the end user wants to do?

(In reply to comment #70) > This BUG show just how out of touch with reality Firefox's developers are. Who > gives a rat's ass about whether the program is following some protocol properly > or not. To the end user it is not doing what it has been told to do and is > therefore a bug. Thanks for the bile. I agree that this is a Firefox bug to be fixed as soon as possible. That's why I stirred the pot, and why this bug will be fixed in the next release. But your comment is worse than useless in getting this bug fixsd. It's not as if "Firefox's developers" actually said this bug shouldn't be fixed. Clue: Mozilla is an open source project, and our bug database gets comments from any loudmouth who wants to give an email to get a login. Don't assume all such people are "Firefox's developers". Keep it productive, if not civil. /be

People should take a look at bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=321744">321744</a>. It's basically about Firefox not honoring the "do this automatically..." check box, but it has nothing to do with the Content-Disposition header.

(In reply to comment #72) > People should take a look at bug <a > href="https://bugzilla.mozilla.org/show_bug.cgi?id=321744">321744</a>. It's > basically about Firefox not honoring the "do this automatically..." check box, > but it has nothing to do with the Content-Disposition header. See bug 315536. /be

Comment on attachment 208411 [details] [diff] [review] Patch for the core code per comment 38. + mMimeInfo->GetPreferredAction( &action ); probably more in line with the style of this file to remove the additional spaces (though the file is inconsistent...)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Firefox 1.5 on Mac OS X 10.4.4 +Confirm that 'Do this automatically is ignored. Also, if I attempt to edit the actions entry in: Preferences | Downloads | View & Edit Actions I cannot choose an application. The exact behavior is this: 1. Goto View & Edit Actions 2. Click on Change Action... (in my case for VCF, which is a vCard file) 3. Pick 'Open them with this application:' 4. Browse... to and select Address Book.app 5. [Address Book is not filled in, seems to be ignored] 6. Click OK 7. [My entry for VCF shows the action as 'Open with', but nothing more] Interestingly, in step 4, the icon for Address Book is shown, but nothing is filled in as the name of the application.

Follow-up: Why is there no 'Add New Action' option on the 'View & Edit Actions...' dialog? This would be the place, wouldn't it?

Eric Everman: this is a core bug... discussions about what features firefox UI provides or doesn't provide doesn't really belong here...

Fixed on trunk. The core issue, that is. Please take remaining Firefox UI issues to Firefox bugs.

Comment on attachment 208411 [details] [diff] [review] Patch for the core code per comment 38. I think we want this behavior change on the 1.8.x branch.... Risk is that an existing embeddor that depends on current behavior will suddenly not get promps coming up in some cases. But this is a Gecko policy decision, really, so I think this is ok.

Comment on attachment 208411 [details] [diff] [review] Patch for the core code per comment 38. bz is module owner and requested approval, so I'm going to mark branch-1.8.1+ for him

Fixed on branch.

*** Bug 325551 has been marked as a duplicate of this bug. ***

Many membership torrent sites (torrentbits clones) use attachement in their download.php scripts. If needed I can provide URLs (in private) that shows this bug. If this is 'fixed' as per comment #38 the correct resolution imho would be WONTFIX _or_ bug 325551 should be reopened, since that one is for firefox specifically. The whole point is that since core seems to throw up the dialog before any extension/plugin/dowloadmanager even has a chance to kick in it CAN NOT be made to work if the user wants to open something even after this 'fix'. This actually boils down to a removal of functionality. Please re-read comment #30.

See comment 79. There are other bugs on Firefox to fix the UI, and bug 325551 should have been marked as a dup of those.

*** Bug 327948 has been marked as a duplicate of this bug. ***

Well, let me also one more "confirming the bug." I my case Firefox ignores default action for *.jpg files, as does with many, many others. The box "Do this automatically for files like this from now on" is checked, and I still get the confirmation dialog. My default application for *.jpegs is the well known Irfanview. The file name is all in capital, if it might be of interest. Worrisome in this case is the very long list of "I cannot reproduce" kind of replies and consequently, no fix is provided for the nuisance. With the complex profile data filing of Firefox I even do not any idea where is my current user profile! For example, I can see the size of my cache, but the setup applet does nto volunteer the directory of the cache! Otherwise I would have tried to quote here my settings for automated file actions. You also indicate this as "resolved fixed." What is fixed, if I may ask?

What's fixed is the core bug (as you can tell by readin this bug). You're not seeing this bug (and the bug you're seeing is well known and has been filed for years). Please don't add any more spam to this bug, ok?

How about just fixing the download actions bug (and other bugs) before release? Frankly I find it pretty incredible that you release something without going through the Options menu and checking that it all works. In fact I find it so incredible that I don't believe it, I'm left believing that Mozilla couldn't really care less about the experience of users. One journalist who'll be giving you a negative write-up.

30 April 2006 How about just fixing the download actions bug (and other bugs) before release? Frankly I find it pretty incredible that you release something without going through the Options menu and checking that it all works. In fact I find it so incredible that I don't believe it, I'm left believing that Mozilla couldn't really care less about the experience of users. One journalist who'll be giving you a negative write-up.

(In reply to comment #90) See bug 315536 where this will be fixed... hopefully by Firefox 2.0 if the technical issues behind it are not insurmountable.

I'm trying to get this work properly, the work web server (unfortantly I dont have access to the source) is using a php script to create the pdf and then launched via fpassthru() and everytime I open it ask if I want to open it via acrobat everytime regardless from the "do this automatically from now on", or the always open in "acrobat" option Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060721 Firefox/2.0b1

(ok, lets try that again..) I'm trying to get this work properly in the latest branch builds, the work web server (unfortantly I don't have access to the php source or the server). A php script generates pdf and then launched via fpassthru() It opens a perfectly valid FF "Open Dialog" and suggests acrobat regardless of the "do this automatically from now on" is selected, it will still open the "Open Dialog" Window, could anyone make a testcase that could defeat this patch? (if I explained it properly) format of the url, http://somedomain.com/sendpdf.php?type=receipt&transact_id=115831 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060721 Firefox/2.0b1

I don't think this is fixed. For some sites every time I click on a torrent file the dialog appears even with the checkbox ticked.

See also bug 354400

Just to add to other experiences recounted here ... [see comment #69] I've used every version of FF and the failure of the download manager to remember "do this automatically..." settings has happened with each and every version from 1.5 onwards. I check each new release and, so far, have consistently had to revert to 1.0.8 to avoid this extremely annoying bug. 1.0.8 has never, repeat, never failed to honour a "do this automatically ..." setting for any filetype. So the obvious question is what is different about the download manager in subsequent versions which leads to the same files (never mind filetypes) being treated differently?

Bug 331259 is essentially a duplicate of this syndrome posted for Firefox. The current disposition indicates that a fix will be implemented in FF3 M11. It also indicates that it is in the Download Manager. Does this imply that it will be reflected in a future SM release as well or is there a different Download Manager for SM builds ?

WRT to RFC compliance, there is a parallel discussion in Bug 331259 starting with Comment #25: >[...] > Of course Firefox could ignore the Content-disposition header but then it > would not be standards-compliant. The operative word in the RFC 2183 extract is "should not". According to RFC 2119 #4: "SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." Thus, the suggested change (always allow the user the option of automatic action regardless of content disposition type) can be implemented without violating RFC 2183.

As I said in that bug, the real problem is that doing that will break a number of sites.

Another point of consideration when implementing these changes - Bank of America's on-line banking downloads for Quicken or MS Money are coded with content-disposition:attachment. With the current FF/SM implementations, this forces the user to answer the dialog on every download, even though the only practical use of the file is to be opened by the targeted finance application. A discussion with BOA's technical support indicated that the rationale for this (vs. :inline) is a function of the way IE handles downloads. If the download invokes an application directly, IE will NOT save the file on the user's system. This unlike SM/FF behavior which always saves the file. They are unwilling to change this at this point as their IE users are accustomed to the file download.

Uh... The point is that SM/FF does not always save the file either. We will happily delete temp files that we open in helper apps. This is precisely why we have to honor the content-disposition setting: sites use it to enable users to save the file, and if we just opened it in an app the user might not be able to do that.

(In reply to comment #100) Certainly that might be the case. However, the suggested change would require a pro-active decision on the part of the user to invoke automatic handling of a specific disposition type. If the result breaks the site for some reason, the user would always have the option to revert back to manual handling.

The suggested change in _this_ bug was that selecting "always handle in helper app" for a type on one site, without any content-disposition involved, would thereafter apply to all sites and all content-disposition values. If there is now another proposal (presumably in another bug), that's great. But that discussion belongs in said other bug.

(In reply to comment #102) My experience is on SM/FF on OS X. In the instance of automatic d/l handling, the target app is opened with the downloaded data as well as the data being saved in a file in the user's selected download destination. This behavior can be exhibited with similar downloads from CitiBanks online banking site which encodes their downloads as inline.

OK. I didn't catch that subtlety in the description. As this fix is described in the core / file handling component, does that imply that it would be reflective in both future FF and SM builds ? Bug 331259 (similar syndrome) indicates FF/download manager component.

> My experience is on SM/FF on OS X. Ah, yes. The OS X mess. Historically Mac users expect all downloads to be dumped to their Desktop, apparently. So we never delete temp files on Mac, unlike other OSes. Of course non-fanatical Mac users actually want the files deleted, etc, etc. I can see making this behavior different on OSX only if the preference to delete temp files is not set. Please file a separate bug on that. Bug 331259 seems to be about a slightly different problem and is being hijacked with content-disposition discussion, as far as I can tell. And yes, the code changed in this bug applies to all Gecko apps. However the front end can avoid prompting if it wants to: we tell it exactly why we're asking it to prompt.

Looks like Bug 331259 started as an issue with FF where the d/l manager would remember the "do this automatically..." and "open with" settings (radio button and helper app), yet still prompt the user for action. It then morphed into a different discussion from regarding standards compliance and over content disposition handling. In the case of SM, the d/l behavior is slightly different. The dialog will still appear, but the "always perform this action..." option is grayed out, the target application is remembered, yet the "save it to disk" option is always checked. If it would help, I can supply screen snapshots for both FF and SM (OS X build) with a download disposition of attachment.

Yes, the morphing should never have happened. And yes, I know what the Seamonkey behavior looks like... I implemented most of it. ;) I'm still not sure what problem you're trying to solve, but this (resolved) bug is not the right place to be solving it.

What I was looking for was to have the user option of invoking automatic helper action for disposition:attachment be the same as for in-line assuming there is a match to a defined MIME type definition. Essentially, honor the MIME handling options present in Preferences/Navigator/Helper Applications and make them stick. It appears that there have been a number of bugs started at one time or another on this behavior. Bug 331259 was opened for FF / Download Manager. Coupled with its' "morphing" from the original request, should a new bug be started with SM or core as a baseline ?

I think the core behavior here is largely correct: notify the UI that there is a load with a certain type and content-disposition:attachment. What the UI does with that is up to the UI... Also, as I said, I could see an argument for changing the core behavior in the case when we're going to save the file anyway (Mac only, basically). That should go into a separate bug from any UI issues.

I just want to clarify, at this point the core is properly notifying the UI about the content-disposition, and the UI is capable of handling the attachment any way it sees fit (including silently), and it is the UI and UI alone that is making the decision? bz's last comment 111 about possibly "changing the core behavior in the case when we're going to save the file anyway" seems to contradict the idea that the core is already handing the UI all the power to handle things as this bug requested. At this point bugs about the issue are being marked as duplicates of *this* bug or bug 331259, both of which are marked as fixed. The actual functionality that users are intending when filing all these bugs is not being achieved, and we need to know which component *that* bug needs to be filed for, or which bug needs to be reopened or whatever.

More (especially wrt Firefox behavior) in bug 453455.

Sorry to add to the noise, but ... I have read all the comments, RFC 2183, RFC 2616 (esp. 15.5 Content-Disposition Issues), etc. RFC 2183 is for email (not HTTP). RFC 2616 is HTTP and explicitly states that "Content-Disposition is not part of the HTTP standard." I understand some of the security issue(s) and the philosophy that attachments require user action(s). If the underlying behavior is WONTFIX then, in this case, the "do this automatically" checkbox should not be available and should be replaced by text indicating the issue. I will try to put this comment with the correct bugs. For me personally, this is a king size pain esp. with streaming media whether or not I want to use a plug-in or an external program. If I right-click and "Open Link in Ext. App." then I can get my streaming audio. Again for me personally, I do not even get the dialog because I get the ZoneAlarm download dialog and must download the (entire) file, then run it. Thanks for listening.

Please direct me to an extension that fix this. For example by ignoring the Content-Disposition header when "Do this automatically for files like this from now on." is selected. Thanks!

Answer to my own post. This extension https://addons.mozilla.org/en-US/firefox/addon/inlinedisposition/ changes Content-Disposition regardless of "Do this automatically for files like this from now on." is selected or not. I would prefer if it depended on "Do this automatically for files like this from now on." for the Content-Type too.

Update: After additional consideration it's enough if Content-Disposition is changed regardless of "Do this automatically for files like this from now on." This still allows full control.

I have here the same problem with Windows 7 and Thunderbird 38.2.0. It is not possible to use the inlinedisposition addon because it is not compatible with this version. On my other workstation with Ubuntu 15.04 and Thunderbird 38.2.0 I can open the attachment and set "do this automatically ..."

UPDATE: I copied the mimetypes.rdf file from firefox to the thunderbird profile to solve this problem. The problem was especially on this workstation, on my test workstation with the same environment thunderbird work like expected.

I confirm that "do this automatically for files like this" doesn't work when Content-Disposition:attachment is used. This means that this bug is not fixed and should be reopened or labeled as WONTFIX (see https://bugzilla.mozilla.org/show_bug.cgi?id=236541#c84 and https://bugzilla.mozilla.org/show_bug.cgi?id=236541#c114). (I also confirm that addon InlineDisposition is a workaround)

Reporter, can you also confirm that "do this automatically for files like this" doesn't work when Content-Disposition:attachment is used?

According to bug 453455 (status=REOPENED), "do this automatically for files like this" doesn't work when Content-Disposition:attachment is used, **only when "open with" is selected**