Closed Bug 331259 Opened 18 years ago Closed 13 years ago

checking "do this automatically for files like this from now on" doesn't have any effect on future downloads of same file type

Categories

(Toolkit :: Downloads API, defect, P3)

Product:
Toolkit
Component:
Downloads API
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9beta2

People

(Reporter: dvir.gassner, Assigned: erik.staats)

References

Details

Attachments

(5 files, 2 obsolete files)

How settings are
28.27 KB, image/gif
Details
image showing mime type
28.90 KB, image/png
Details
Attempting to change Download Actions-nothing to pick
57.57 KB, image/jpeg
Details
Changed the download app to create urn:mimetypes:root container if it doesn't exist.
4.79 KB, patch
Details | Diff | Splinter Review
Screen shot of Bug 331259 showing "OK" grayed out
24.53 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Checking "do this automatically for files like this from now on" when downloading any file type, doesn't have any effect on future downloads of the same file type. Firefox doesn't seem to "remember" my selection, even not in the same session.

Reproducible: Always

Steps to Reproduce:
1. Download any file type.
2. Check the box near "do this automatically for files like this from now on".
3. Download the same file type again.

Actual Results:  
Download dialog box appeared again

Expected Results:  
Download/Open action should start automatically
(In reply to comment #1)
> Bug 236541 ?
> They are obviously related, but for me it happens with any file type.


(In reply to comment #0)
> Checking "do this automatically for files like this from now on" when
> downloading any file type, doesn't have any effect on future downloads of the
> same file type. Firefox doesn't seem to "remember" my selection, even not in
> the same session.

    Yeah, there's definately something messed up with this feature. The annoying behavior with the "do automatically" checkbox has been in Firefox since before 1.0.
(In reply to comment #3)

>     Yeah, there's definately something messed up with this feature. The
> annoying behavior with the "do automatically" checkbox has been in Firefox
> since before 1.0.
> 

It's my understanding that this bug affects *all* Firefox users, regardless of platform, so I'm baffled why this bug has been allowed to persist for so long.  It certainly is very frustrating to users like me who use Firefox to read their e-mail and who are constantly having to open file attachments.
Attached image How settings are — 
May be me and all i know has this problem are missunderstood the way firefox should be configured for "Automatic download" to work correctly. So this is screen of our settings window.
this is a major bug, and its happening with the new firefox2
how about if you disable your extensions...flashgot might be interfering here.
This is most likely due to the server setting the MIME types for the file to 
'application/octet-stream' which is a generic MIME type.  Firefox always asks about these files under this MIME type, even if the check box has been checked before (the behavior is different in the recent Firefox 2 betas, meaning that they put up a different 'Save As' dialog box for these types.)

More details:
http://forums.mozillazine.org/viewtopic.php?t=458336&postdays=0&postorder=asc&postsperpage=15&start=30
http://forums.mozillazine.org/viewtopic.php?t=465567

My opinion is Firefox should check nominal file extension when it has nothing else to go on besides the MIME type 'application/octet-stream'.
The MIME type doesn't appear to make any difference for me.  Strangely, FF obeys the setting (to automatically open with Media Player) for MPG files but not WMVs.  MPGs and WMVs are configured the same way in the "Download Actions" dialog -- to open automatically in Media Player.  I see one difference though -- I have the plugin option for WMV but not MPG.
Okay, I made it worse.  I removed WMV from the "Download Actions" dialog, hoping that re-adding it would fix the problem.  But now when I click a WMV link I get a dialog with only "Save File" and "Cancel" buttons, no option to open Media Player or use a plugin.
Sounds like this behavior is confirmed...  What is the next step?
This is still definitely going on, and very confirmed. Hopefully we can get this takin care of soon but I would like to add that for me it only seems to do it on files that need a plugin IE; quicktime and wmvs  
I am not sure why this bug is labelled unconfirmed.

For me every time I load a file mime type video/x-m4v, firefox asks me "What should firefox do with this file?" I have selected use "mplayer" to open it more than once and I have checked the box "Do this automatically for files like this from now on". 

Strangely, these days, if I just press OK, firefox somehow remembers that it has to use "mplayer" and opens properly. But the question is why does firefox ask this  question everytime. 

Please reopen the bug if you feel so. Adding an attachment of the dialog box.
I am also unclear why the bug is UNCONFIRMED. On my machine it happens every time. I am running Firefox 2.0.1 and I get it all the time. 

Can someone with "canconfirm" privilege change the status, please? It's being going one for 6 months and many versions of Firefox already...
Agreed - this bug is confirmed and completely reproducible - it should be set to confirmed... this is one of my biggest bugbears in Firefox.
When trying to change the download actions, there's no action to pick (Tools > Options > Content > "File Types" area > Manage... > Download Actions dialog shows nothing.
I've also had this bug for as long as I can remember, and still currently in 2.0.0.1

This is a showstopper as far as I'm concerned; affects every user, UI control doesn't work.
As a note, it occurs even when the server provides a MIME type, and Firefox knows the right app to open the file in (it lists it). All that needs to be done is to hit "OK" and the file opens in the app. But Firefox won't do it automatically.
Confirming based on comments. There is obviously some problem here, even if not everyone sees it.

All the people who have commented: what we need is a reproducible test case. Ideally, it would be an attachment uploaded to this bug with a particular MIME type set, where the behaviour was wrong.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
100% Reproducible test case (at least for me):

Log into Yahoo Mail (I am using the normal mail, not "Yahoo Mail Beta" they keep suggesting I try.

Receive an email containing a JPEG as an attachment.  Click either "View" or "Scan and Save to Computer" or "<filename>.JPG", any of the three bring you to the same screen, Yahoo's file attachment download screen.

This screen tells your four things:

"File name: 	S5000308.JPG
File size: 	2176kb
File type: 	image/jpeg
Scan result: 	No virus threat detected."

Below it are two buttons "Download Attachment" and "Back to Message".

Click "Download Attachment".

I then get the "Opening S5000308.JPG" dialog.  In the "What should Firefox do with this file?" area, the "Open with" radio button is already selected, the correct application is chosen in the pulldown (in my case, firefox.exe, which I had to go find the first time, why doesn't firefox offer itself as an option for file types (like images) that it can display?  Anyway, that's a separate issue and not related... and it didn't make a difference when I had "Windows Picture and Fax Viewer" as the default application).

AND... "Do this automatically for files like this from now on." IS CHECKED... and has been ever since the first time I tried to download a jpg and checked that box myself.

Oddly enough, the "OK" button is sometimes greyed out until I click somewhere on the dialog, I don't have to change anything...  Probably unrelated though.

Anyway, after I click "OK" it will open the file.  If I go back and download the same exact file, I get the same exact sequence of events.

Try this a couple times.  The SECOND time I tried to open a jpg, I am not sure it prompted me with the dialog... I do not remember.  I know every time after that it did.  So it is possible that it remembered my setting exactly once.

On the "Download Actions" dialog (from Tools|Options|Content), jpgs are listed as:
Extension: JPG
File Type: JPEG Image
Action: Open with Firefox

I created an example Yahoo account that you can use to test this bug.  The account is 'DemoOfFirefoxBugForMozilla' and the p@ss w0rd is 'mozillafirefox' backwards.  I forwarded an email to the account so all you have to do is log in and download the attachment.  Note that I asked Yahoo to disable this account's ability to send messages.

If this is not enough information, please email me and request specifically what more you need.  I realize you asked for an attachment to show this bug, but the screenshots attached are already jpegs and firefox doesn't 'download' them, it just shows them.  I'm not sure exactly what the difference is.  However I saved the third attachment ("CannotGetDownloadActionsToPopulate.jpg") to disk, then emailed it to my yahoo account, and when I try to download it from my email I get the same behavior (prompts me even though "do this automatically" is checked).  So I don't think it is anything about the file itself, instead it is how Yahoo presents it.

I'm using Firefox 2.0.0.2 which I just downloaded.  This is on Windows XP.
I'm on MAC OS 10.3.9.
ON MY DESKTOP iMac--When I click on a link to a .wmv streaming file, that I have dialogue-box clicked to OPEN, it works perfectly and streams.

ON MY G4 POWERBOOK laptop--When I do the same thing, and have previously clicked the box to ALWAYS OPEN the file (and stream the video)...a problem occurs: 
THE FILE DOWNLOADS instead of going to the link and streaming. Last week it was a 130MB video...it took 15 minutes or so to DOWNLOAD (vs. automatically opening and streaming. I could not find any preferences (beyond what I've selected already multiple times) to make it work.

Please advise.
I just noticed that there are more comments than votes. Please vote on this issue to let Mozilla know it has to be fixed soon! Also, I only had this problem after downloading Firefox 2.0 not in version 1. This is bug is a problem for all downloads.
I've just voted for this as it's a real annoyance. I can't remember when this started happening with me -- at least 6 months. I'm running the latest FF Win build (2.0.0.3). Like other users above, my "File Types" box in "Options > Content > Manage" is empty, and no amount of checking "Do this automatically..." will add anything to it.
I did a little testing and this is what I found:

It is not a bug, this is the expected, standards-compliant behavior. Here's why:

Firefox always displays the download dialog box if the server sent a "Content-disposition: attachment" header line in the response. It should do so even if you previously checked the "do this automatically for files like this" checkbox because RFC 2183 defines the attachment disposition type as this: 

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

Therefore, if the server sends a "Content-disposition: attachment" header line then this should override the user's choice to do some automatic action for the given file type.

If the server doesn't send a "Content-disposition" header at all or it sends a "Content-disposition: inline" header line then Firefox will automatically perform the action you previously set.

So the problem is not with Firefox but with the server that sends a content-disposition header line when you wish it would not. 

Of course Firefox could ignore the Content-disposition header but then it would not be standards-compliant.

Two problems with your statements:

1) You're quoteing e-mail standards, not web standards. The same paradigms don't apply.
2) This is talking about e-mail attachments, not file transfers (which are inherantly distinct from any body) with an HTTP header. Email attachments are being defined there as seperate from the body, while HTTP transfers are always seperate from the body, as it were.

Regardless, the question is, does this bug (behaviour) occur when firefox doesn't receive a Content-Disposition header? Because from the comments and my own experience, this bug occurs regardless of any Content-Disposition headers.
RFC 2183 is a MIME extension, so if the server sends something with a mime type then this standard should be applied.

I tested the behavior of Firefox with my own server, and I found that the download dialog is always displayed when the Content-disposition: attachment header is sent by the server. Otherwise it does not display the dialog box if you set the automatic behavior previously for the file type.

This (clicking on a download for a type which was previously connected to a specific action) used to work with Webshots Desktop, but it now seems to behave as all above have described.  I don't know if the Webshots website has changed what it sends when you click on a download request button, or if something has changed in Firefox.  It started happening about a week and a half ago to me (kt is now May 26, 2007.  It is annoying, since it requires more typing (or mousing) on my part, but I wouldn't call it a show stopper.  I am using Firefox 2.0.0.3 on Windows XP Pro, SP2, with all security patches thru April 15, 2007.  Incidentally, there is nothing shown in the "Download Actions" popup and no way that I can add one.  What the heck is the "Search" window for?  Typing in there accomplishes nothing, exception frustration.  I get enough of that already, so I quit typing (;).
Ah, yes, Webshots Desktop!  That's exactly why I've recently become interested in this issue also.  I also have the experience that the downloaded file was automatically processed by Webshots Desktop until recently.  I'm using Firefox 2.0.0.3 on Windows XP Home, SP2.  To the best of my knowledge, I didn't change anything in Firefox, so I tend to think the new behavior may be caused by some change at Webshots.com, but I certainly don't know.

You mention a "Download Actions" popup.  I don't get a "Download Actions" popup.  I get an "Opening ..." popup (apparently the word "Opening" followed by the long name of the file to be downloaded.

Neither do I have a "Download Actions", but I have a selected radio button "Open with" followed by "Webshots.Extension(default)".  Also, "Do this automatically for files like this from now on" is checked, but the action is now never done automatically.  Firefox seems to know what application to use, but doesn't automatically use it.

As stated, this is more annoyance than problem.
Sorry about mixing two different applications in my comment.  The "Download Actions" reference is to the Firefox options, not to something popping up when clicking on a file link.  I get the "Opening ..." popup as well, with the action filled in, but not automatically getting done.
I also starting seeing this with Webshots a few weeks ago.  Yes, it is more of an annoyance than a problem, but I would like to see it fixed.
At least in the case of Webshots, the "problem behavior" seems to no longer be happening.  I don't know why.  I don't think Firefox has been updated.  Perhaps something changed at Webshots (again?).
It would appear that Webshots has changed something so the popup doesn't happen.  I had not updated Firefox, as far as I know, and the problem has gone away for me.
checking "do this automatically for files like this from now on" worked for me on Minefield/3.0a7pre several days before, but now it's broken - minefield just popup "Opening ..." window

dmose - could some of the handling stuff have broken this recently?
This bug irritates me.  I noticed it for over a year now and just now did a search for it.  Confirmed file types for me are .Torrent files and .NZB files.
Same irritation factor, here. I can also confirm it at least does it on torrent files.
why didnt you vote then?  I did...
If an RFC describes how an application interacts with the user it should be treated as a recommendation or a default action.  The user should have the ultimate say on how an application interacts with that user.  That's why we have an Options screen.  And how many settings in about:config violate RFC recommended behavior?

I agree that we should be standards compliant for a new profile.  But after that any user changes must be respected (as long as it doesn't harm another users system).  If an RFC stated that the maximum number of browser tabs must be 3 and if that was enforced with no way to change it, people would switch away to another browser that didn't follow the RFC in droves.

While this bug isn't going to make me switch browsers it does make me want to smash my mouse and/or keyboard every time I'm forced to press that OK button again.  If I can't find a plugin to fix this I may just download the source myself and build my own personal version that doesn't go out of it's way to drive me nuts.

For info: this has also been reported as bug 354400, and is discussed in this thread: http://forums.mozillazine.org/viewtopic.php?t=356337&start=30
I've had this problem ever since Firefox 1.x.  It happens all the time when downloading .torrent files.
Work now on Trunk, but work only if you manually select application to open
Selecting "default" casually do nothing
Can we finally please just fix this?  If this is the expected behaviour, then the dialog boxes should be changed because they lead the user to expect another behaviour entirely.  One way or another, this annoying problem should be fixed.
Stop posting comments asking about the status, saying that it affects you, etc.  If you care enough about the bug, vote for it, cc yourself, or propose a fix.  Posting comments that I just asked to not be posted is counter-productive to getting this bug fixed.  Thank you.
Flags: in-litmus?
Whiteboard: READ COMMENT 45 BEFORE POSTING A COMMENT!
When the automatic option is checked, the download app attempts to add the new MIME type to the "urn:mimetypes:root" RDF container resource.  However, an exception is thrown if the resource doesn't already exist as a seq.  This patch catches that exception and creates the seq resource.

This bug also affects Songbird (see http://bugzilla.songbirdnest.com/show_bug.cgi?id=4830).

I wasn't sure whom to ask for a review.  I added Christian since he reviewed a patch for the similar bug #236541.
Attachment #283721 - Flags: review?(cbiesinger)
Something tells me that the fix for this might be better in nsHandlerService.js perhaps?
(In reply to comment #47)
> Something tells me that the fix for this might be better in nsHandlerService.js
> perhaps?

Indeed, it certainly would be, but helperApps.js hasn't been updated to use the handler service yet.
This bug is a big embarrassment for a product like FireFox. Especially since it's been present for so long.
Flags: blocking-firefox3?
Does that mean we need a patch for nsHandlerService.js in addition to the one that's already posted here?
(In reply to comment #50)
> Does that mean we need a patch for nsHandlerService.js in addition to the one
> that's already posted here?

I don't think so, since the handler service already makes sure the container exists when retrieving it in _ensureAndGetTypeList <http://lxr.mozilla.org/mozilla/source/uriloader/exthandler/nsHandlerService.js#893>.

That method does things a bit differently from the patch in this bug, however, so it's worth comparing the two in case one or the other should do something differently.  In particular, I notice that the patch in this bug doesn't ensure an arc from urn:mimetypes through NC:MIME-types to urn:mimetypes:root, which is part of the default mimeTypes.rdf files <http://lxr.mozilla.org/mozilla/find?string=mimetypes.rdf>.
Flags: blocking-firefox3? → blocking-firefox3+
Here is a quick fix for those that are annoyed enough, assuming you have access to a hex editor. Search for the string 'content-disposition' within Firefox.exe and replace it with something else. This string should appear exactly twice. Doing so will force firefox to ignore the content-disposition and the file associations will be used when the checkbox is checked.
Target Milestone: --- → Firefox 3 M10
Attachment #283721 - Flags: review?(cbiesinger) → review?(comrade693+bmo)
Whiteboard: READ COMMENT 45 BEFORE POSTING A COMMENT! → READ COMMENT 45 BEFORE POSTING A COMMENT! [has patch][needs review sdwilsh]
Comment on attachment 283721 [details] [diff] [review]
Changed the download app to create urn:mimetypes:root container if it doesn't exist.

r-
Please see comment 51
Attachment #283721 - Flags: review?(comrade693+bmo) → review-
Whiteboard: READ COMMENT 45 BEFORE POSTING A COMMENT! [has patch][needs review sdwilsh] → READ COMMENT 45 BEFORE POSTING A COMMENT! [needs new patch]
Eric, is there any chance you'd be up for iterating on that patch in the relatively near future (M10/M11 timframe)?
Priority: -- → P3
Target Milestone: Firefox 3 M10 → ---
Sure.  What is the M10/M11 timeframe?  I'm coming at this from Songbird, so I'm not as tuned in to the Mozilla timelines.
That'd be fantastic; the current theory is that M10 codefreeze will be around Dec 3; I'm not sure about M11, but I'd guess sometime in January.  I'll reassign the bug to you; if at some point it becomes clear that you aren't going to have the bandwidth, please let me know, and I'll try and recruit someone else.  Thanks!
Assignee: nobody → erik.staats
(In reply to 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 recommended change (user override) can be implemented without violating RFC 2183.
Target Milestone: --- → Firefox 3 M11
So what behavior are we planning to implement here, exactly?

Note that automatically handling content-disposition:attachment with a helper app without prompting the user to save WILL break sites.  That's why we always prompt when we see this header.
(In reply to comment #58)
> So what behavior are we planning to implement here, exactly?
> 
> Note that automatically handling content-disposition:attachment with a helper
> app without prompting the user to save WILL break sites.  That's why we always
> prompt when we see this header.
> 

The behavior being implemented is to automatically handle files without prompting the user when the user has selected to do so and all of the headers say it's OK to do so.

In other words: "Exactly the opposite of what many people have been asking for".

Looks like I'm stuck recompiling my own version each time a security fix comes out.  With my fix when I say don't bother me again, it doesn't bother me again.

I tried the hex edit trick above to avoid having to build my own version but it has an unwanted side effect.  It causes the filename to be random when saving files (ie downloading attachments from Gmail).

(In reply to comment #60)
> In other words: "Exactly the opposite of what many people have been asking
> for".
> 

  My patch fixes a case where checking "do this automatically.." does not have any effect.  It addresses a very specific case where a particular file is not initialized.
  I'm pretty certain it's doing more of what people want and not the opposite of what people want (unless they want checking "do this automatically..." to not have any effect).
  As for the behavior with certain headers, my patch should not change anything.


I think Erik Staats is on the right track here.  Thanks for taking up the problem Erik.
Changed patch #283721 to address comment #51.
Attachment #283721 - Attachment is obsolete: true
Attachment #289343 - Flags: review?(comrade693+bmo)
Whiteboard: READ COMMENT 45 BEFORE POSTING A COMMENT! [needs new patch] → READ COMMENT 45 BEFORE POSTING A COMMENT! [has patch][needs r]
Comment on attachment 289343 [details] [diff] [review]
Changed the download app to create urn:mimetypes:root container if it doesn't exist.

Please add const Cc and const Ci to the top of this file, and instead of Components.classes use Cc and Ci instead of Components.interfaces.

I don't really feel comfortable reviewing the rdf changes however, so I'm going to defer to Myk for those.
Attachment #289343 - Flags: review?(myk)
Attachment #289343 - Flags: review?(comrade693+bmo)
Attachment #289343 - Flags: review+
Comment on attachment 289343 [details] [diff] [review]
Changed the download app to create urn:mimetypes:root container if it doesn't exist.

>Index: toolkit/mozapps/downloads/content/helperApps.js
>+// namespace prefix
>+const NC_NS                 = "http://home.netscape.com/NC-rdf#";

Nit: this duplicates the functionality in NC_URI.  Seems like we should just use that in this file.

Also, it's not clear why ensureAndGetTypeList is generic when it'll only ever be called for "mimetype".  Seems like it'd be better to make it specific to its use.

Of course, ultimately this code should be replaced by calls to the handler service, which has now all the necessary methods, if I recall correctly.

But this is fine for now.  r=myk
Attachment #289343 - Flags: review?(myk) → review+
Whiteboard: READ COMMENT 45 BEFORE POSTING A COMMENT! [has patch][needs r] → READ COMMENT 45 BEFORE POSTING A COMMENT! [has reviews][needs final patch for landing]
(In reply to comment #65)
> (From update of attachment 289343 [details] [diff] [review])
> >Index: toolkit/mozapps/downloads/content/helperApps.js
> >+// namespace prefix
> >+const NC_NS                 = "http://home.netscape.com/NC-rdf#";
> 
> Nit: this duplicates the functionality in NC_URI.  Seems like we should just
> use that in this file.
> 
> Also, it's not clear why ensureAndGetTypeList is generic when it'll only ever
> be called for "mimetype".  Seems like it'd be better to make it specific to its
> use.
> 

  I just copied all of this from mozilla/source/uriloader/exthandler/nsHandlerService.js.



Modified path 289343 to address comment #64.
Attachment #289343 - Attachment is obsolete: true
Note, I don't have write access to the mozilla CVS.
Keywords: checkin-needed
Whiteboard: READ COMMENT 45 BEFORE POSTING A COMMENT! [has reviews][needs final patch for landing] → [has reviews][can land]
Checked in, thanks for the fix!

Checking in toolkit/mozapps/downloads/content/helperApps.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/helperApps.js,v  <--  helperApps.js
new revision: 1.15; previous revision: 1.14
done
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [has reviews][can land]
Target Milestone: Firefox 3 M11 → Firefox 3 M10
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120405 Minefield/3.0b2pre 

- > verified fixed
Status: RESOLVED → VERIFIED
How do I install this code so that my browser uses its default actions now? I am not very savy when it comes to installing .js code
(In reply to comment #71)
> How do I install this code so that my browser uses its default actions now? I
> am not very savy when it comes to installing .js code
It is fixed for Firefox 3.
(In reply to comment #72)
> (In reply to comment #71)
> > How do I install this code so that my browser uses its default actions now? I
> > am not very savy when it comes to installing .js code
> It is fixed for Firefox 3.
> 

I am not sure that it is. Just did a clean reinstall of Firefox 3 Beta 2. Same exact bug. Is there any other way to install the .js code?
(In reply to comment #73)
> I am not sure that it is. Just did a clean reinstall of Firefox 3 Beta 2. Same
> exact bug. Is there any other way to install the .js code?
Clean install with a new profile?
> any other way to install the .js code?

I second this


In addition to voting for this bug, I wanted to add two comments:

1) It is not quite accurate to say checking the box has "no effect."  It does seem to have the effect of remembering your selection.  Although the dialog box still comes up (which is a bug), the preference also comes up as the application to use for the file, but it still has to be confirmed.

2) There is a second aspect of this bug which is that the "OK" button on this dialog box is grayed out for a while and you have to click on it a couple of times to make it active and then you can click on OK to make it effective.

Thanks to whoever can fix this!

See comment posted 4/24/08 on additional aspect of this bug that when the dialog box opens the OK button is grayed out until clicked on to activate it and then you can click on it to execute.
I second begone_1999's comments and want to note that this is not fixed in Firefox 3.0b5 even though its status is "VERIFIED FIXED" and the Target Milestone is "Firefox 3 beta2"
I can also confirm that this issue is not fixed in Firefox 3.0b5.
Verified NOT fixed in Minefield 2008043007, Windows Vista SP1 x32, with a test case consisting of 

http://h33t.com/torrents.php

with muTorrent configured in Tools > Options... > Applications. Furthermore, the dialog box has no disabled components---it has muTorrent preselected and has the 'do this every time' box already checked. Despite, in fact, _asking_ me every time.

The reason for this is that h33t, and others, sends a content-disposition: attachment header, which somehow throws Firefox into this buggy mode. Test case data follows...





Firebug shows the following response headers for the h33t (broken) test case:

Date	Fri, 02 May 2008 02:21:32 GMT
Server	Apache/2.2.3 (CentOS)
X-Powered-By	PHP/5.1.6
content-disposition	attachment; filename="Smooth Jazz Cafe - Vol 09 [MP3 192-320][h33t][schon55].torrent"
Keep-Alive	timeout=15, max=1000
Connection	Keep-Alive
Transfer-Encoding	chunked
Content-Type	application/x-bittorrent


Whereas for any downloads on http://thepiratebay.org/recent, it shows

Content-Type	application/x-bittorrent
Etag	"2263758963"
Last-Modified	Fri, 02 May 2008 03:21:00 GMT
Server	lighttpd
Content-Length	15160
Date	Fri, 02 May 2008 03:26:58 GMT
X-Varnish	1774813109 1774787051
Age	221
Via	1.1 varnish
Connection	keep-alive
(In reply to comment #80)
> The reason for this is that h33t, and others, sends a content-disposition:
> attachment header, which somehow throws Firefox into this buggy mode. Test case
> data follows...
no, when they send it with the attachment header, we are supposed to always ask regardless.
Bug 285976 covers disabling the checkbox when we know it won't work (e.g. in the content: disposition case).
Oops. It looks like I didn't click through to enough links. Sorry for the n00bness.

For what it's worth, this is very un-userfriendly. I told my browser what I want, and it's refusing to give it to me :(. I guess that's what writing an extension is for? Hah...
This bug is NOT fixed. The bug has nothing to do with any requirements set forth in RFC 2183, it is simply a bug that is possibly based on the misinterpretation of some Asperger's suffering programmers' socially hostile interpretations of RFC 2183. RFC 2183 says that the user should be asked to perform an action to download the attachment. If the user has specifically checked a box and selected an application or behavior to be followed in a circumstance, and has additionally asked not to be prompted when that circumstance arises again, that is a LOT of action by the user.

No, a program should not automatically download an attachment. There is a significant difference between automatically doing something, and following a specific set of rules that have been manually set by the user in advance and can be manually changed by the user again at any time.

"Of course Firefox could ignore the Content-disposition header but then it would
not be standards-compliant."

Nobody is asking for the header to be ignored. We're saying that the header should be used, specifically to perform the action the user has manually configured the application to use when that header is encountered with the other circumstances set forth by the user.

What is the purpose of using computers if not to automate tasks to the user's specifications?
I agree with Nathaniel's point, if not his tone.  If the user has been asked previously what action to take, and as explicitly stated that they want the same action to be used in the future automatically, then the user's expectation is that the same action will be taken automatically.

I'm all for adhering to standards, but the number one most important standard in application design is to give the user the behavior they expect.

As you all know, the content-disposition header does more than just signal that a user decision is required, it also allows the server to specify a reasonable filename to use when saving the file (automatically to the temp directory, or suggested in a Save As dialog).  Without the content-disposition header (for example, using only the content-type header) there is no other mechanism to suggest a filename.  Therefore, the only UA behavior that satisfies the user's expectation (of not being prompted after they've checked the box for a specific media type), while still allowing a filename to be suggested, is to repeat the behavior automatically regardless of a content-disposition header until they go into "Manage..." and specify otherwise.
Folks, you should file a new bug if you want the behavior to change.  This bug fixed an issue with this code-path.  What you are describing is a different issue.  Complaining about it in the comments of a resolved bug isn't going to accomplish anything.  Please file a new bug.
No, we are not describing a different issue. We're discussing bug #331259, which states quite clearly "checking 'do this automatically for files like this from now on' doesn't have any effect on future downloads of same file type". That is still the case for some file types. There is no ambiguity to the wording of the bug, or the statements made in this thread that fully admit the behavior has not been changed for all such cases.

If you want to enter a new bug that describes the subset of behavior that was fixed, feel free. Those of us who've been watching this same bug for several years would like it to actually be fixed someday and not simply dismissed by maintainers more concerned with closing issues than addressing them.

I'm sorry if my tone is not appropriately reverential for all the hard work it took to move the goalpost, but the ball is still sitting on the 50 yard line and you're claiming a touchdown.
Flags: in-testsuite+
Flags: in-litmus?
Flags: in-litmus+
Nathaniel, I think you know already that I completely agree with you. So I'm going to play devil's advocate for a bit.

1) Mistitled bugs/bugs with outdated titles are somewhat common, so it's reasonable to ask for a new bug for new behavior.

(However, I am somewhat afraid that unless it were filed by someone with 'authority' that it would be promptly ignored, and certainly not giving the "blocking-firefox3" tag.)

2) Be sure to click through to all related bugs. Boris Zbarsky, who is apparently very much in touch with the codebase and also holds a large amount of authority, has several times outlined some interesting corner cases which might merit consideration. While I would say that he's being overly annoying about sticking to the stupid-behavior in all cases simply because these corner cases work against the smart-behavior, his points are definitely worth taking into consideration. It'd be great if you could 'refute' these corner cases here, in the sense of showing exactly why they do not invalidate your above reasoning.

(However, my impression is that Boris Zbarsky is holding things back much more than they need to be, possibly out of stubbornness at this point. That is, despite having good points, he has not convincingly shown why they invalidate the entire idea of fixing this stupidity; he seems to latch on to them as a way to prevent progress, and since he's authoritative nothing gets done.)


======

All that said, I think it's telling that this bug has so many votes and subscribers, presumably many of which are not developers. For example, I am a user who's been blissfully enjoying Minefield builds as just a way to get some nice features that Firefox 2 doesn't have. But I finally got mad enough at this behavior to Google a solution and, upon finding out that this was a known bug, signed up for Bugzilla and started posting comments, etc. Take that as you will.
I don't know why people are arguing.  If there is a box that says 'do this automatically from now on', then it should do what you ask it to.  If that functionality shouldn't be there, there shouldn't be the box to tick in the first place!

Take it out, or leave it in and make it work...
I agree that Firefox should ask for permission before opening files with "content-disposition: attachment". However, the text "do this automatically for files like this from now on" should be changed because it is inaccurate. I think something like "remember this action" or "remember this selection" would more appropriately describe what marking the checkbox actually does.
If the logic is that the user should have to click to download, then I agree the check box should go away or be replaced by something like "remember this preference."  However this still does not deal with the fact that the "OK" button is greyed out until you click on the dialog box, so you have to click at least twice.  Requiring one click should be sufficient to meet the "rule."
Product: Firefox → Toolkit
Hey guys, this is still an issue with Firefox 3.0.1.  I'm using linux (Gentoo) if it matters.  Is this fixed for everyone except me or there some other bug I should add my vote to?  Thanks.
I agree. If I tell Firefox to do something (not keep pestering me every time I open a file of a given type), I expect it to do so. The failure to do so is, in my opinion, a bug. It's annoying that it's now marked as "Verified fixed" when it isn't as far as most users are concerned.
I *think* this issue is now considered as Bug 285976, although the title for that one is pretty obscure.  And it doesn't sound like there's any movement on it :( 

If anyone has a hack or a patch to workaround this issue, I've love to hear about it.
Maybe our only recourse is to develop an addon that bypasses the filetype dialog box.  That addon can use the same application settings in the options menu but use its own pathways and own dialog.  Maybe even a toolbar that pops up for automatic downloads so you can change settings for future downloads of the same filetype.
You guys are all nuts:

To the developer who won't fix it:
It's a feature (checkbox) that is clearly interpreted by all users as a way to elect to bypass RFC 2183.  Why is it interpreted by so many this way?  Because all the other browsers offer the ability to bypass it this way.  It's a user selectable bypass.  It's the user's ability to control his own security level.  get off your horse.

To the end-users who appear to have waited for years:
If you view 10 files, you're wasting 10 pop-ups with 10 clicks time.  100 files? 100 extra keystrokes.  Making this a low performance browser for things like video viewing.  Want speed? use another browser.

I'm uninstalling.  It's worked fine for years in IE.  Too bad.  very nice browser otherwise.
Eric,

RFC 2183 is a security guideline.  The specific verbage of the check box presumes to be a security bypass.  User selectable security bypass options are a widely accepted standard.

How about you make it work (like it does in other browsers) but pop a warning? All these users in this thread are really asking for the checkbox to work as a security override, so post a security warning (one-time) if the elect to use it.
David,

My fix was an upstream patch to Mozilla from the Songbird project.  I don't actually work on Firefox.  I fixed a bug where the checkbox setting would never be saved regardless of any server settings or file type.

Perhaps at this point, a "bypass RFC 2183 security guideline" preference checkbox feature request should be created.  However, some other developer will have to take this on.  I'm quite busy with Songbird related work.

(In reply to comment #97)
> Eric,
> 
> RFC 2183 is a security guideline.  The specific verbage of the check box
> presumes to be a security bypass.  User selectable security bypass options are
> a widely accepted standard.
> 
> How about you make it work (like it does in other browsers) but pop a warning?
> All these users in this thread are really asking for the checkbox to work as a
> security override, so post a security warning (one-time) if the elect to use
> it.
I've created Bug 453455, requesting a new feature to provide an option to bypass the RFC 2183 security guidelines.  Let's move the discussion there.
I finally have a solution for this bug. Since Chrome is available for OS X, I just switched. Firefox has never been better!
The problem still persists. Why is it marked as fixed?
(In reply to comment #101)
> The problem still persists. Why is it marked as fixed?

See comments 61 and 98.  An enhancement request has been created as bug 453455 as mentioned in comment 99.
I agree with Boyan Yurukov in comment 101, but I have made my point in bug 453455, comment 64, so I will not elaborate further here.
I also agree with comment 101.
Checking "do this automatically for files like this from now on" STILL doesn't have any effect on future downloads of same file type.
Therefore, this bug should not be misleadingly marked as "verified fixed". Search engines point here, and people get confused.
There is a blog page that was meant to boost some awareness of this ridiculous bug and hopefully find someone willing and able to fix it. Not much has come of it yet, but a clever guy from Russia made a Firefox add-on that provides this much needed functionality:
http://www.dothisautomatically.com/?p=1#comments
I still hope that someone within Mozilla wake up and do what should be done long ago.
This is NOT fixed.  The problem is still afflicting users.  

Bug #453455 is a duplicate of this one.  However, since this one is closed and 453455 is still open, I am marking this as a duplicate of 453455 even though 453455 was submitted 2-1/2 years after 331259.
Status: VERIFIED → RESOLVED
Closed: 17 years ago → 13 years ago
Resolution: FIXED → DUPLICATE
Please don't change the resolution of a two year old fixed bug that had a patch that landed.  Bug 453455 is about the case for the attachment type of download, but as comment 61 says, that's not what we chose to do here.  These are different, but similar bugs.
Status: RESOLVED → VERIFIED
Resolution: DUPLICATE → FIXED
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.

Something tells me that the fix for this might be better in nsHandlerService.js perhaps?
<a href="https://hfive555.com/en/918kiss">Hfive5 login 918kiss</a>

Something tells me that the fix for this might be better in nsHandlerService.js perhaps?
https://hfive555.com/en/918kiss

This bug seems to have reappeared in Thunderbird 91.2.0 on a Mac running Big Sur 11.6.

I set a default viewer for a file type. I select "do this automatically for files like this". But I still get prompted with the "You have chosen to open" window the next time around. I have tried closing and reopening Thunderbird.

Depends on: 236541
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: