Closed Bug 453455 Opened 16 years ago Closed 2 years ago

Make "do this automatically for files like this from now on" work even with "content-disposition: attachment"

Categories

(Firefox :: File Handling, enhancement, P5)

Product:
Firefox
Component:
File Handling
Type:
enhancement
Points:
8

Tracking

()

Status:
RESOLVED FIXED
Milestone:
98 Branch
Tracking Flags:
Tracking Status
firefox97 --- disabled
firefox98 --- fixed

People

(Reporter: erik.staats, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: sec-want, ux-control, Whiteboard: [fidefe-Outreachy2021] [p-chrome] [sg:want] [Advo] [qx] [fixed by bug 1710941][adv-main97-])

Attachments

(2 files)

Comment 18 Concept Mashup
18.98 KB, image/png
Details
screenshot of browser file reception dialog that has a grayed out "remember" item
14.33 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

Many users have requested in bug 331259 and others the ability to automatically download files even when the file is sent with the "Content-disposition: attachment" header.  They would like to ability to bypass the security guidelines in RFC 2183 and automatically download these files.

The fix in bug 331259 addressed an issue with saving the automatic download checkbox settings and did not attempt to address any issues related to RFC 2183.

Hopefully, this bug will serve as a better location for the discussion of the user requests, since bug 331259 has been marked fixed.

Reproducible: Always
Version: unspecified → Trunk
Bugzilla is not a place for discussion. Please use nntp://news.mozilla.org/ mozilla.dev.apps.firefox or http://groups.google.com/group/mozilla.dev.apps.firefox
Automatically downloading attachment sent files is bug 285976.
(In reply to comment #2)
> Automatically downloading attachment sent files is bug 285976.

It sounds like bug 285976 is to disable the "automatically download" checkbox with "Content-disposition: attachment" headers.  That's not what users are requesting in bug 331259.
Sounds reasonable to me.  As far as I know, web sites use "content-disposition: attachment" as a security measure to mean "don't treat this as a web page served from this server", not "make sure the user is prompted before the file is downloaded".

Boris seems to be claiming otherwise in bug 285976, but I'm not convinced.  Even with his "deliberately unhelpful PDF reader application" use case, remembering the action as "download" wouldn't be a problem.  The only problem would be remembering the action as "open with (deliberately unhelpful PDF reader application)" and then not figuring out how to undo that remembering.  That problem exists even without content-disposition: attachment and I don't think working around it is a major use case for content-disposition: attachment.

RFC 2183's wording only makes sense to me in the context of mail messages, not in the context of link clicks.  I don't see how fixing this would be a security problem.  What would be a security problem is "fixing" bug 185618.

Boris, are you actually against having this UI change in Firefox, or are bug 236541 comment 38 through 48 just about implementation details?
Status: UNCONFIRMED → NEW
Component: General → Download Manager
Ever confirmed: true
Product: Firefox → Toolkit
QA Contact: general → download.manager
Summary: Provide option to bypass RFC 2183 security guidelines when downloading files. → Make "do this automatically for files like this from now on" work even with "content-disposition: attachment"
I can live with remembering the "save" action, no problems.  We just shouldn't be remembering the "open in app" or "view in browser" actions in this case.

Note that the behavior websites _really_ want here, typically, is to force save with no user choice (what IE does), and we're just giving the user more options.  We've had bug reports about the user having said options, but we sort of stand by that.

This is basically what bug 236541 comment 38 says, and honestly, I'm sort of tired of going over this argument again and again and again....
Not fixing this bug (and I mean a real fix, not Boris's preferred one) has caused me to switch to Chrome, which doesn't have this problem.

Sorry guys, Firefox was fun, but I download way too many .torrents to put up with this shit. I just want to open the damned things with with muTorrent instead of going through a downloading + finding in Explorer + opening adventure safari.
Can we *please* not have this turn into bug 331259 and actually follow bugzilla etiquette [1] here?  That means no comments saying "Please fix this" or "This made me switch to browser X".  The only impact it has on getting this fixed is a negative one because developers don't want to pay attention to a bug that has all sorts of comments like that.  Please don't scare away the developers.

[1] https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Whiteboard: [p-chrome]
From what I can tell reading through some of the backlog litany here, there are two issues concerning this bug:

Issue 1: "content-disposition: attachment" was created specifically and only to allow a server to specify "this file should be treated as an 'attachment' and only saved to the disk, not displayed inline"

Is there any other reason why servers would use "content-disposition: attachment" other than to signal that the file is not to be loaded inline? Are we running into a case where the actual State of The Web differs from the Intent of the Spec?

Issue 2: When users click "[ ] Always do this" the UI should listen

bz, you point out in comment 5 that this is probably OK to do as long as the actions don't include "view inline" or "open in app." I understand your objection to "view inline" since that's the entire point of "content-disposition: attachment", but "open in app" is simply saving the user a double click and I don't see any real argument why just because something is meant to be an attachment doesn't mean that if a user takes the action to click on it we can't automate the "open" step after the "download" step.

It sounds to me like what we actually want to do is ensure that "view inline" is never offered for files that are served with "content-disposition: attachment". Is that bug 285976?
bz isn't CCed, but he explained his reasons for why opening with a helper app is not a good idea in bug 236541 comment 40, bug 236541 comment 102, and bug 236541 comment 107.
(In reply to comment #8)
> It sounds to me like what we actually want to do is ensure that "view inline"
> is never offered for files that are served with "content-disposition:
> attachment". Is that bug 285976?

No. That bug is about disabling the "always do this" check box for content-disposition: attachment (because in those cases we're not going to honor it anyways).
(In reply to comment #9)
> bz isn't CCed, but he explained his reasons for why opening with a helper app
> is not a good idea in bug 236541 comment 40, bug 236541 comment 102, and bug
> 236541 comment 107.

bug 236541 comment 40 - this is about helper apps that view the content inline, which isn't the same as "Open in app" which launches an external application

bug 236541 comment 102 - this is about files which are downloaded to a temp directory, used by a helper app which views the content inline, and then deleted

bug 236541 comment 107 - OSX downloads now default to the Downloads directory, and seems to also be related to a common request to have PDFs viewed inline

In all these cases, I'd be fine if the files served with content-disposition: attachment were *not* handled by helper apps (which I see as equivalent to "view in browser") but rather forced to be downloaded and handled by external apps.

Allow me to make my point clear with an example: let's say I've got a page with a link to a PDF or a WMV:

 - if served using content-disposition: attachment, the options that the user would have would be "Save to disk" and "Open with [some app]". In both cases the file would be downloaded using the download manager, if the user selected "Open with [some app]" we'd run the open step as well. "View in Browser" would not be available, nor would we hand the file to a plugin/viewer registered to handle that content.

 - if served any other way, plugins/viewers would be able to download the file to a temp directory, view the content inline and then dispose of it; "View in Browser" would be an option in the handler window

This allows the UI checkbox to be honoured while, I believe, covering the cases and spirit of the RFC.
(In reply to comment #8)
> Is there any other reason why servers would use "content-disposition:
> attachment" other than to signal that the file is not to be loaded inline? Are
> we running into a case where the actual State of The Web differs from the
> Intent of the Spec?

Blogger uses content-disposition: attachment on images ex. http://4.bp.blogspot.com/_7ZYqYi4xigk/SLwuftMrEII/AAAAAAAABtU/eTT5kKVNxBE/s1600-h/collage_and_text.png which is actually a HTML page and if you right click and choose view image it is served as an attachment.
(In reply to comment #12)
> Blogger uses content-disposition: attachment on images ex.
> http://4.bp.blogspot.com/_7ZYqYi4xigk/SLwuftMrEII/AAAAAAAABtU/eTT5kKVNxBE/s1600-h/collage_and_text.png
> which is actually a HTML page and if you right click and choose view image it
> is served as an attachment.
I'm betting that's so people cannot hotlink images to their site from another site.
(In reply to comment #5)
> I can live with remembering the "save" action, no problems.  We just shouldn't
> be remembering the "open in app" or "view in browser" actions in this case.
>
> Note that the behavior websites _really_ want here, typically, is to force 
> save with no user choice (what IE does), and we're just giving the user more
> options.  We've had bug reports about the user having said options, but we 
> sort of stand by that.

Boris, I thank you (or whoever did it) for changing the behavior to disable the dialog when the option to "save to disk" is selected, and allowing users more choices and more freedoms to browse the web how they see fit. I believe the current issue (and it is an issue for many people) should follow the same spirit. No one's asking for an easy UI implementation that would easily bypass RFC 2183 (and thus increase the likelihood that people will accidentally make the change and not realize its consequences). Changing this behavior/setting could deliberately be buried and difficult to implement, but for those who really want to change it they can still do so. 

> This is basically what bug 236541 comment 38 says, and honestly, I'm sort of
> tired of going over this argument again and again and again....

We shouldn't be arguing about this. It's a simple matter of allowing the user to do what THEY want, not what YOU want or what some guidelines specify. It's not a law--no one is going to hunt you down, put a gun to your head, and force you to change it back. You could make this change if you wanted to. There are plenty of informed people out there who would gladly take the risk of inadvertently (or even unknowingly) downloading something harmful to avoid the *daily* hassle of this dialog box. 

Regarding the frequency of this behavior, in my experience files with the content-disposition:attachment header are at least as common as those with other headers that don't (supposedly) pose a security risk per RFC 2183. Actually now that I think about it, what would prevent malicious code from being placed into a file with a header that doesn't require RFC 2183???

The bottom line is that this is about user choice & freedom. Please consider making this change.
(In reply to comment #11)
> bug 236541 comment 40 - this is about helper apps that view the content inline,
> which isn't the same as "Open in app" which launches an external application
> 
> bug 236541 comment 102 - this is about files which are downloaded to a temp
> directory, used by a helper app which views the content inline, and then
> deleted
> 
> bug 236541 comment 107 - OSX downloads now default to the Downloads directory,
> and seems to also be related to a common request to have PDFs viewed inline
> 
> In all these cases, I'd be fine if the files served with content-disposition:
> attachment were *not* handled by helper apps (which I see as equivalent to
> "view in browser") but rather forced to be downloaded and handled by external
> apps.

The "helper apps" bz is referring to in comments 40 and 102 and what you call "external apps" are the same thing. They are distinct from plugins, which show content inline in the browser. Boris is talking about external apps that won't let you save the file while you're viewing it, which, due to the fact that we delete temp files after they've been used, means that there's no way to ensure that users are able to save the file (i.e. treat it like an attachment).

(The fact that we don't delete temp files on Mac, and save them on the Desktop by default, means that he is less concerned about allowing automatically opening the files in helper apps on Mac. This is what comment 107 is about.)

I'm not sure that I buy his argument, because I can't really think of any apps that don't let you save a copy the file once it's opened (e.g. "Save as").
Since there doesn't appear to be consensus on what to do, could you at least provide an about:config option for people who really want to change this ?
Summary of the elements of the issue:

1) RFC 2183 specifies content-disposition: attachment trigger a 'Save response as...' user prompt, requiring action by the user.

2) HTTP 1.1 echos this

3) User's desire is to have a save yet seamless low click experience

4) The desire of content providers to have access to differing ways of interacting with the user and user agent.

Three of the four elements support the current implementation.  So how can the UI be improved in a manner that does not detract from the spirit of RFC 2138?  It only requires that the 'Save response as...' dialog box be presented to the user so they can take appropriate action.  This does not require the user agent to have 'Save response as...' as the selected option, nor does it specify the other elements that can/cannot appear on the 'Save response as...' prompt.

This can allow for several UI options:
- Allow the 'remember my choice' to remember the last program that was chosen to be entered as the default helper app with browse next to it.
- Have 'open with' as the default selected option
- Integrate the list of programs into the dialog box and eliminate the 'browse' button.  An example of this would be take the existing list and integrate it on the right hand side of the dialog box, showing only if 'open with' is selected

Comparing the current version to a version with all three of these options implemented:

Current - user wishes to save file
-------
1. Click link
2. Click ok, saves to default location

Current - user wishes to open with program
-------
1. Click link
2. Click 'open with' option
3. Click 'browse'
4. Double click helper app
[possible](5). Click remember choice (thinking it will save this choice for next time)
(5-6). Click ok

Proposed - user wishes to save file
--------
1. Click link
2. Click save file
3. Click ok

Proposed - user wishes to open file with program
--------
1. Click link.
[if previously 'remembered']
2. Click ok.

[if first time for this type]
1. Click link.
2. Click 'open with'.
[optional](3). Click 'remember selection'
(3-4). Double click helper app

Lets say the user chooses to save 1 file and open 2:
- Current method total clicks: 12-16
- Proposed method total clicks: 9 (both when remembering and when not)

The reverse scenario to save 2 files and open 1 (assuming first time):
- Current method total clicks: 9-10
- Proposed method total clicks: 9-10

This I believe clearly shows why many users see this as a UI issue.  Those who use helper apps more often than saving are clicking 3-7 extra times where it is not needed.  This can further be improved by allowing 'Remember my selection' to also save the default selected radio button as well.  This allows users who save more often to select that as the default for that type and save 1 click per download there after while adding that click back to the 'open with' option.  

This proposal conforms to the RFC spec and requires the user to make a selection and improves the user experience across the board.

I'll be at the Changing The World conference on the 15th, I'm eager to hear Mike Beltzner's take on UI
Carrying over vlad's blocking flag from bug 469746
Flags: blocking1.9.1?
(In reply to comment #20)
> Carrying over vlad's blocking flag from bug 469746
So, I don't think that this should block 1.9.1 for a number of reasons (in no particular order):
1) We've shipped with this for ever (really, for ever)
2) This would make us violate RFC 2183 (cc'ing bz for this, and bz - sorry;  I know you are tired of discussing this issue)
3) We have no UX spec for this, and as submodule owner, I find it unacceptable to make this just work (for being in violation of RFC 2183).  In reality, that means I find that this should be WONTFIX.

With that said, I think comment 18 has some potentially better user experiences, and we should file a bug for the right user experience.
(In reply to comment #15)
> I'm not sure that I buy his argument, because I can't really think of any apps
> that don't let you save a copy the file once it's opened (e.g. "Save as").

Acrobat Reader, if the right bits are set on the PDF.  It'll let you edit the PDF, and read it, and print it, but not save it.  Yes, it's weird.  Yes, other PDF viewers have similar behavior if those bits are set.  Yes, it's required by the PDF spec last I checked.  Yes, plenty of PDFs out there have those bits set; about half of the job application PDFs Emma is running into as part of her job search seem to.  The expectation is that you fill it out, print it, and send it in, but don't save it, apparently.

It's also possible to create Word documents that behave this way, for what it's worth.  I don't know _why_ people do it, but they do.  Just Google "prevent save as in Word" for all the fun you want.

I've also encountered some image viewers (admittedly, harder to find nowadays) that have no "save as" at all, because they're just viewers, not editors.

Comment 15 is correct in terms of terminology.  If I meant "plug-in", I would say "plug-in".  "Helper app" is what we've used for external apps all along.

(In reply to comment #14)
> Actually now that I think about it, what would prevent malicious code from
> being placed into a file with a header that doesn't require RFC 2183???

Nothing, on your own site which would then get blacklisted as soon as the problem is discovered.  On the other hand, obeying RFC 2183 prevents you from uploading your malicious stuff to some other site that just wants to let people upload things.  At least if said other site is a little careful.

(In reply to comment #18)
We should already be saving the helper app the user selected last.  If we're not, that's a bug (and a regression from the XPFE dialog).  If we're not doing that, please file.  The only other thing proposed in comment 18 is that we remember the last-selected choice but don't execute it.  I would be fine with that, I think, since it gives the user a chance to select the other option if the default one is giving broken behavior.

(In reply to comment #21)
(1) Yes
(2) imo, yes, if we just run a helper app without prompting.  Certainly yes if
    we handle internally in any way, but I don't think anyone's suggesting that.
(3) Agreed on lack of spec.

That all said, if we in fact don't save the user-selected helper app, _that_ should be considered for blocking status, imo.  Even if Firefox has shipped that way "forever".
Attached image Comment 18 Concept Mashup — 
I made a (very) quick mockup of my proposal.  Basically if open with is selected the options are available right away with "browse" for additional options.  It has a "Select this option next time" instead of "do this" so the user knows it will not be automatically done.  If "Save as" is selected it should disable but still show the right hand portion of the box.
(In reply to comment #22)
> That all said, if we in fact don't save the user-selected helper app, _that_
> should be considered for blocking status, imo.  Even if Firefox has shipped
> that way "forever".

Yep, that's the core of the issue I think -- the same dialog shows up as with non-attachment downloads, except that the "Open With: [...]" bit is always blank, even if there is a helper app defined for that document type.  Also, the "Always do this" checkbox is misleading in this case.  I think it would be perfectly acceptable if this dialog always popped up for attachment downloads, but without the checkbox, and with the helper app pre-filled if defined.
(In reply to comment #22)

> (In reply to comment #14)
> > Actually now that I think about it, what would prevent malicious code from
> > being placed into a file with a header that doesn't require RFC 2183???
> 
> Nothing, on your own site which would then get blacklisted as soon as the
> problem is discovered.  On the other hand, obeying RFC 2183 prevents you from
> uploading your malicious stuff to some other site that just wants to let people
> upload things.  At least if said other site is a little careful.

Well, then that's the point: Malicious files will be blacklisted as soon as they are discovered, so that should have no bearing on how the user wants to interact with their content. Without question, safeguards can and should be put in place, but they should not prevent a user from deliberately choosing to ignore them. There are innumerable ways in which a user could deliberately expose themselves to harm that are not barred by Firefox or any internet rules. So why is this case any different? I believe it is because the developers are misinterpreting the MIME standards.

I believe most (if not all) of this behavior occurs with application/octet-stream MIME types. According to RFC 2046 (addressing security issues in MIME types), under section 4.5.1 for application/octet-stream entities:

   "The recommended action for an implementation that receives an
   'application/octet-stream' entity is to simply offer to put the data
   in a file, with any Content-Transfer-Encoding undone, or perhaps to
   use it as input to a user-specified process.

   To reduce the danger of transmitting rogue programs, it is strongly
   recommended that implementations NOT implement a path-search
   mechanism whereby an arbitrary program named in the Content-Type
   parameter (e.g., an 'interpreter=' parameter) is found and executed
   using the message body as input."

A plain reading of this text reveals that it is RECOMMENDED to avoid automatically executing on undefined (/octet-stream) MIME types; it is not a strict rule to prevent such action by the user. 

According to RFC 2183, the purpose of the MIME framework is to provide "for the interchange of message content, but leaves presentation issues solely in the hands of mail user agent (MUA) implementors". This text suggests it is up to Mozilla to define how to handle presentation issues, and thus it is within the purview of developers to determine how Firefox handles these MIME types. I agree that the default behavior should be for increased security, but the MUA (program=Firefox) should not prevent the user from selecting another less secure behavior should they so desire. 

RFC 2183 does not explicitly state the MUA must disallow any potential non-secure behavior:

   "There are security issues involved any time users exchange data.
   While these are not to be minimized, neither does this memo change
   the status quo in that regard, except in one instance.

   Since this memo provides a way for the sender to suggest a filename,
   a receiving MUA must take care that the sender's suggested filename
   does not represent a hazard."

The key text here is "A RECEIVING MUA MUST TAKE CARE THAT THE SENDER'S SUGGESTED FILENAME DOES NOT REPRESENT A HAZARD". Thus, it is up to the MUA (and by extension the user) to determine what is and is not a hazard. It does not require the implementor to prevent the MUA from choosing a potentially hazardous behavior. 

Finally, I believe most of the issue hinges on the following text from RFC 2183 section 2.2:

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

A close reading of this text reveals that it does not specify this behavior must be followed each time the user receives an 'attachment' MIME type. Instead, the operative words are "should" and "might". It does not REQUIRE any particular behavior, rather it SUGGESTS what should be done. 

Therefore, since neither RFC 2046 nor RFC 2183 require the MUA or MUA implemetor to restrict any particular behaviors with respect to application/octet-stream MIME types, the desired change for this bug is not barred under those standards. 

Furthermore, it is not apparent to me who enforces these standards and what the potential liability would be for non-compliance. 

As such, I implore the developers to provide a workaround to this UI issue.
> I think it would be perfectly acceptable if this dialog always popped up for
> attachment downloads, but without the checkbox, and with the helper app
> pre-filled if defined.

That's the behavior it had in Seamonkey (then Mozilla suite) after the last time I touched it.  If someone broke things since, we should fix them, of course.  It might be good to have a new clean bug with just this, not the various other changes people want to make here, as the goal, and just fix it in the Firefox unknown content dialog.

I think I'm done here, since this bug is getting really spammy, just like every single other bug I've seen on this issue.
(In reply to comment #26)
> That's the behavior it had in Seamonkey (then Mozilla suite) after the last
> time I touched it.  If someone broke things since, we should fix them, of
> course.  It might be good to have a new clean bug with just this, not the
> various other changes people want to make here, as the goal, and just fix it in
> the Firefox unknown content dialog.
I agree, and I've filed bug 470332 to get that done.  As it stands, this bug is WONTFIX.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
(In reply to comment #26)
> I think I'm done here, since this bug is getting really spammy, just like every
> single other bug I've seen on this issue.

Spammy? I think the number of posts (and duplicates of this bug) speak to how many people want to see this FIXED (and their frustration at the developer's stonewalling). This issue isn't going to go away just because you don't want to deal with it. 

Answer me this: how much effort would it require to implement the desired change? If it's really a cost-benefit (dev time/effort vs. the number of people who want it fixed) analysis, then say so. I can accept that. I just find it hard to believe the developers really want to adhere to standards (at least their interpretation of them) as the reason this UI behavior can't be changed. 

If you can't answer my comment #25 with a cogent argument against it, then tell us all what the real reason is for not addressing this concern?
No one is "stonewalling" - Shawn's filed bug bug 470332 on remembering the choice of helper apps, bug 285976 exists to cover not offering to remember when we won't save the choice, and I've just filed bug 470514 to cover making it possible to remember "Save as" as a choice, per comment 5. I think those bugs together address most concerns adequately.
Flags: blocking1.9.1?
I'm just a user, so excuse the stupidity, but could someone please tel me why I have to click twice to view a photo?  Firefox clearly recognizes that it is a picture, but is ignoring my request to just open the GD thing.  Is it a security issue?  If yes, why won't you let me be the judge of my own security?  Alternately, why have the box to check?  This is not a new annoyance, I've just been too lazy to do anything about it before.  But I've just had to open a couple of dozen pictures from my Yahoo email by clicking TWICE AS MUCH as I should have to, and it has officially gotten to be a pain in my butt.
I am in the same boat as comment #31. Very frustrating. Does the status "wontfix" mean that this will never be fixed and if so can anyone give a reason a layman can understand ?
Layman explanation:

* You don't need to click on anything to get something sent with content-disposition: attachment.
* Automatically opening arbitrary content enables drive-by attacks (go to page, page sends content containing an exploit, app gets launched to open content, user gets owned).
* This behaviour is effectively "let any page on the Internet pass arbitrary content to this application"
* Explaining why the oh-so-convenient option is actually compromising your system security is rather ineffective (see the various research on the incredibly poor effectiveness of warning dialogs).
Mike Connor's explanation doesn't make sense in the context of this bug report.  A web page could do all that stuff by just not sending the "content-disposition: attachment" header.
Without kicking a dead can, the point is to prompt the user as to what they want to do with the file and prevent people from just "assuming" it's safe because the browser launched it right away.  It also allows flexibility for developers as to how they want their files to be interpreted client side as well as keeping with the standard.  If any discussion should take place on the issue it should be in context of updating the standard to be more specific.

The only thing I see that could be improved to make all sides happy is what was proposed above (see my comment #18 and related attachment).  This is the only way I can see currently to adhere to the standard, prompt the user, but still allow for fewer overall clicks for the user.  Allows for security, standards, and is user friendly.
Setting aside for a second the issue of why it can't or won't be done, I haven't seen any explanation for why the option even exists for selecting "do this every time".  Why can't the option be grayed out or not included?
I tried this in IE and note there is no 'remember my choice' box . 

So at least as a dumb user I am not frustrated by thinking 'remember my choice' actually does something.

 I agree with Comment #25 - 
"Well, then that's the point: Malicious files will be blacklisted as soon as
they are discovered, so that should have no bearing on how the user wants to
interact with their content. Without question, safeguards can and should be put
in place, but they should not prevent a user from deliberately choosing to
ignore them."

I think the point of  users who want to see the JPG immediately are people are like me who want to see the image without junking up their hard drive. Seeing as how I am taking the responibilty by checking the  'remember my choice' box, I don't see why "Big Brother" wont just leave me to my fate.

I am resigned to not having it work as I want it to but could you please remove the 'remember my choice' box ? Its like waving a red flag at the bull.
Doesn't the function in question detect the file extension _and_ give the user
the option of method to open said file?  

#1) If I choose to always open file type "*.virus" with program "Destroy My
Entire Network", that's entirely MY BAD.  

#2) if I decide to always open file type "*.jpg" with program "Picasa" how in
the heck could this do bad things to my computer again????
(In reply to comment #29)
> No one is "stonewalling" - Shawn's filed bug bug 470332 on remembering the
> choice of helper apps, bug 285976 exists to cover not offering to remember when
> we won't save the choice, and I've just filed bug 470514 to cover making it
> possible to remember "Save as" as a choice, per comment 5. I think those bugs
> together address most concerns adequately.

I have not seen any argument against my analysis of the RFC standards in comment #25. This is stonewalling. Everyone who must deal with this asinine behavior will eventually switch browsers. I have.
Firefox's current behavior forces sites to choose between security and usability.  On the Web, content-disposition:attachment means the file should not be considered same-origin with the site.  Firefox punishes sites that use the header by not letting users view the files as easily as they can on other sites, ultimately hurting security.

I'm reopening this because it was resolved as WONTFIX based on a misunderstanding of the security concerns and an overzealous reading of an irrelevant spec.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [p-chrome] → [p-chrome] [sg:want]
Thank you for doing us this favor.  Please also look into https://bugzilla.mozilla.org/show_bug.cgi?id=160144 as it has been 7 years since the bug report has been opened. I believe that that bug has been ignored because of an overzealous misunderstanding of the security concerns
I'm a bit confused...

I'm trying to set up Firefox so that it will always open .nzb files with my newsgroup reader. No matter how many times I tell Firefox to "do this automatically", it always prompts me. The alternative to clicking this every single time seems to be to tell it to always "save as", and then double click the downloaded file. Either way, I have to click twice for each nzb (once to initiate the download, and then once to "activate" it). Is this the same issue that's being discussed in this bug report, and, if so, why are developers so hesitant to allow users to determine how they want their browser to handle file downloads?
I don't know if maybe this is beating a dead horse, but since this still hasn't been fixed after several years i guess i feel obligated to add my opinion:

1. I agree that the current reading of RFC 2138 is overzealous. Firstly, i think there is a very good case to be made for that spec being completely irrelevant to Web browsers (as opposed to actual mail clients). But secondly, and more importantly, i don't think that the behaviour proposed by the others here conflicts with even a strict reading of the recommendation. The purpose of the 'attachment' content-disposition is to prevent the client from opening the file in-line — allowing the user to always open it in an external application is PERFECTLY in synch with that recommendation. An external application is not in-line, even if the file is passed to it automatically, so there is no conflict at all.

2. I think the concerns of the opponents of changing the current behaviour regarding the desires of server hosts are completely valid, but i also think that the desires of the users (and anecdotally i would say it's a LOT of users) trump those concerns. The devs didn't put the wishes of server hosts ahead of those of the users when they implemented pop-up-blocking or the ability to install arbitrary extensions or anything else; what makes this specific scenario so sacred?

3. I think the concerns regarding security and RFC compliance are also valid, which is why the proposed behaviour should be very much an 'advanced' kind of thing — for example, something that would have to be enabled in about:config. Maybe even in a key that has to be explicitly added by the user first, just to add even one more layer of protection. Leaving RFC 2138's recommendation as the default behaviour — but allowing the user to change it with some effort — should please everyone, i'd think.

4. I might go even further than some of the other proponents of changing the behaviour here — i think that, in addition to being able to automatically open in an external application, there should also be the ability to automatically open it in-line, if it's set that way specifically.

For example, someone earlier mentioned how Blogspot (and they're not the only ones) use content-disposition to force normal images like JPEGs to always save to disk. This usage is not security- or usability-related or anything else, it's purely a tactical decision on the part of the host to prevent hot-linking. Some might even call it abuse. This shouldn't become my problem, any more than pop-up ads should — i just want to view the image in my browser like every other image! I should not have to open an external application, or an extra Firefox window even, to do that, if i really don't want to.

5. In summary, i think the following changes should be made to the current behaviour:

(a) The current behaviour should remain as the default, but the UI should be changed to notify users that the action can not be taken automatically when appropriate (this is a separate bug).

(b) An option should be added to enable the ability to automatically perform the selected action for 'attachment' downloads. This option should be sufficiently obscure to protect un-informed users from enabling it without knowing what they're getting into.

(c) Once enabled, option (b) should allow the user to automatically perform actions for individual file types exactly as they can with non-'attachment' downloads — that means saving to disk automatically if desired, or opening in an external program automatically if desired.

(d) An option should be added to enable the ability to view supported file types in-line for 'attachment' downloads. This should probably be a separate option from (b), because the ability to automatically open in an external application is less removed from the spirit of RFC 2318 (or not removed at all, really) than the ability to view it in-line is, and having one action perform both would thus be irresponsible.

(e) Once enabled, option (d) should allow the user to automatically view attachments in-line as specified by the browser's normal download settings (e.g., under Preferences > Applications). This should not pose any threat to usability or security, because these file types would be only the common ones that the browser is designed to open anyway (like JPEGs and PNGs).

An alternative to the above would be to just add 'hooks' so that this behaviour can be altered by extensions, which would allow for more complex download managers to deal with the specifics.
> On the Web, content-disposition:attachment means the file should
> not be considered same-origin with the site.

Unfortunately, that's not all it's used for.  Some sites use it this way (for HTML and such).  Other sites use it to mean "don't view inline" or "let user save" (for images and the like).
Now SeaMonkey is only affected (so far only in 2.0b). So we can expect many
more duplicates (as we had for bug 236541 which is fixed, actually not fixing
what all those dupes were reported for). In the end it is just a horrible user
experience. People choose to do some action and without any warning or hint it
does not happen.

I came to search this because of my bank account. There I encounter the issue.
Certainly there are few sites I would trust more with respect to security!

My logic goes as follows: The user want to handle certain files types by
opening with a named application. He trusts that he has done everything
reasonable (like setting up relevant virus protection etc.). He can launch the
file (after pressing the button or after saving). He wants it and will do it.
The dialog doesn't stop him and hence does not increase security.

Yes, this is not a new argument, but this is what the users experience. They
don't see MIME headers (the dialog box does not display that, but suggests it
will remember a decision made by the user).

pi
It seems kind of arbitrary that the "do this automatically" checkbox is grayed out for "content-disposition: attachment" given that, even if the checkbox is disabled, you can still force files of a particular MIME type to always save if you use the Tool -> Options -> Applications UI, if an entry for that MIME type exists in mimeTypes.rdf. The UI is unable to automatically add/remove MIME type records, so you have to manually edit mimeTypes.rdf. For example, to always save files of type application/octet-stream, insert

<RDF:li RDF:resource="urn:mimetype:application/octet-stream"/>

as an entry between <RDF:Seq RDF:about="urn:mimetypes:root"> and </RDF:Seq>, and add the following just before </RDF:RDF> (last line of file):

<RDF:Description RDF:about="urn:mimetype:application/octet-stream"
                 NC:description="application/octet-stream"
                 NC:value="application/octet-stream"
                 NC:editable="true">
  <NC:handlerProp RDF:resource="urn:mimetype:handler:application/octet-stream"/>
</RDF:Description>
<RDF:Description RDF:about="urn:mimetype:handler:application/octet-stream"
                 NC:alwaysAsk="false"
                 NC:saveToDisk="true"
                 NC:useSystemDefault="false"
                 NC:handleInternal="false">
</RDF:Description>

After making those edits, you can choose to always save the "application/octet-stream" type from Tool -> Options -> Applications, and Firefox should honor the setting, even in cases where the "do this automatically" checkbox would have been disabled because the file was served as an attachment.

If you are being served a different MIME type (e.g., application/x-rar-compressed), do a search-replace on "application/octet-stream".

Live HTTP Headers is useful for finding out the MIME type of the file you are being served:
https://addons.mozilla.org/en-US/firefox/addon/3829

More info on editing mimeTypes.rdf:
http://kb.mozillazine.org/MimeTypes.rdf
But that doesn't work for those of us who want to _open_ every time, I assume?

Since I'm here, I might as well mention an idea I'd had for a workaround: namely, creating an extension that just looks for the content-disposition: attachment header and always removes it. Given that there are a number of extensions to view HTTP headers and others to modify GET/POST data, I would imagine the APIs exist for modifying the headers themselves?

It's on my "to do in my very rare spare time" list, but maybe someone else subscribed to this bug knows enough about the extension APIs to make this a one-hour project? (My problem is that I'd have to learn how to write an extension, which seems like it might take a day or two... even if it would be a good skill to have.)
> But that doesn't work for those of us who want to _open_ every time, I assume?

No, I don't think it does, but I'm not 100% sure - I haven't thoroughly tested that side of it.

When browsing with Firefox I have found that pages seem to have the ability to launch files without user interaction. Upon opening a malicious page you can get the "You are opening..." dialog asking what to do with, for example, an .exe or .pdf file, without ever having clicked on a link to an .exe or .pdf file. I used to have Firefox set up to automatically open PDF files using the Adobe plug-in, but I changed it to "Always ask" after I had to quickly kill a "~.exe" process that was launched by a vulnerability-exploiting PDF that had apparently been opened in the background, without user interaction, by one of my tabbed Google search results. Now I occasionally get the "Always ask" dialog popping up and asking me what to do with a .pdf file, when I never clicked on a link to a .pdf file in the first place (but at least I can click "Cancel" now).

The point I'm getting to is that for "Always _open_ every time" there probably needs to be a quick OK/Cancel confirmation of some kind when files are launched without user interaction.
Hello,

I also have been struggling with this issue, but I have managed to solve it for my own purposes.

I'm using Privoxy [a non-caching web proxy with advanced filtering capabilities for enhancing privacy, modifying web page data and HTTP headers, controlling access, and removing ads and other obnoxious Internet junk]. It's open source software, which im currently using as universal ad blocker.

It can modify http headers, and because my main annoyances are .nzb files i just added the following to configuration file:

{ \
+hide-content-disposition{block} \
}
/.*\.(nzb)

And now Firefox opens these files with the program i've configured. This is of course not the solution for everybody, since it requires installing another software for the background.

I definately would like to see some sort of solution from Mozilla.

Mikko
(I post here instead of risking a new duplicate)

I click a link on a web page, and the dialog appears:
 - telling the file is a PDF document
 - with the selected (radio) option to open it with Foxit Reader
 - unselected radio option "Save File"
 - checkbox "Do this atumatically..." It is checked, as I checked it 1 minute before.

The checkbox is obviously not honored.

It should either be honored or not offered at all.

(FF 3.5.5 on WinXP)
From reading the comments of this and related bugs, it seems to me that the only real security concern here is drive-by attacks where the user has not clicked the link. If this is what is causing developers to resist remembering the user's choice of app and automatically opening without additional interaction then I see the point. This would not be safe, and although my initial thoughts were all centred around "remember my choice when i damn well tell you to", I don't think I should be able to do this as it stands, even in about:config. PDFs provide a good example of a format that often has serious security holes, and the risk of being hit with automatically opened PDFs without clicking deters me from wanting this change. Do I understand the position correctly?

HOWEVER, I am also incredibly irritated by this lack of functionality on an hourly basis and have been for years. There has, despite legitimate concerns, been some stonewalling and stubbornness. I think this bug should focus on technical solutions to what is a clear usability issue. The usability issues exists, regardless of other concerns. Let's fix it. How can we allow users to remember their choice of app for links that they DO click on? There are elements of things like pop-up blocking that seem to have knowledge of whether or not a user made a click. Is this information available in the download code path? Could it reliably be made available? How reliable? The massive majority of cases involve clicking a link, and requiring unnecessary extra clicks when it should be seamless. This needs addressing. I have only *ever* once been targeted by a download I didn't click on. Enabling these attacks is not a good thing, but working around them is essential.

At the very least, for immediate clarity if a real solution requires significant work: the dialogue should be re-worded or better the functionality changed. I believe there is another bug for this already? The remember check-box should be unchecked and disabled if the radio button for open is selected. Even better, check-box and text should be replaced to signify why the choice cannot be remembered. None of these things would constitute this bug being fixed.

I find it hard to see how ex
A suggested solution:
Similar to one of the popup-blocker's code, we could detect if this is an intentional action to download, by looking for explicit click/enter button actions.

If the user did click on it, then we know it is intentional, and if they have requested to bypass the dialog, then bypass the dialog.
i have been struggling with this issue for many years. I have had it with mp3, torrents, nzb files and many of others.

To the developers: If you don't feel like fixing this obvious usability flaw and rather do something else, just say so. Don't hide behind any outdated half relevant specifications. Because now there is absolutely no excuse for not thinking in terms of AND/AND. There is more than one way to protect the innocent from drive-by execution of malicious content AND allow automatic execution of daily or rather hourly of not more often task. Take pride in what you are doing and rather think in terms of solutions. It's quite possible you were not in creative mood when you were presented with this problem the first time and felt like you had to keep defending your decision all this years. Wake up and be a hero :) We will thank you for this!
If the reporter marks this as "blocks bug 565512" I feel it might have a marginally better chance of being taken care of.

I am definitely not in control when I tell the browser to "do X" and it blatantly refuses to, with no explanation whatsoever.
Blocks: cuts-control
Ok, here is what I would expect Firefox to do, from a user perspective:

1) If the server sends me something explicitly marked as download using the attachment header (or as possible drive-by-execution), I would expect the 'Save As' Option to be the default. 
Else it is quite easy to 'just click OK' in the dialog, and your downloaded file is a) somewhere lost in a temp-directory and b) gets executed anyway.
The argument that every 'Open-With' App has a 'Save As' option anyway is not valid, since media-players usually do not provide such an option (at least the ones I use, like VideoLAN player). 

(However it would be helpful to have a 'Save As' option in the Download-manager for downloads to a temporary location, although since temp-files should be deleted after they are used, having a 'Save As' option in the download-manager should therefore count as usage and prevent deletion of the temp-file until the entry is removed from the downloaded-files-list).

2) If I have an 'Open With' option, which I guess selects the application based on the file-extension (since it is available even if 'Always perform this..' is greyed out), the default action (Open with/Save as/..) should be set in the same way the 'Open With' action works, i.e. based on the file extension if the mime-type is not available/incorrect/octet-stream (setting a single default 'Open-with' or 'Save as' action for all 'octet-stream' mime-types is of course not a good idea :) ). 

From a user perspective, I am really not that interested in mime-types and server-configurations. If I get an 'Open With' option, based somehow on something the server sends (mime-type or filename), then the 'Always perform this..' option should work in exactly the same way. This should provide a much more consistent UI-feeling. If the option gets disabled for security or missing-information reasons, the UI should tell me so, not just disable the options.

3) I do not quite see how much good disabling the option does security-wise anyway, since it should be quite possible to just send a malicious PDF using a correct mime-type, which would then be opened automatically again.

4) Another helpful UI improvement (for me..) would be if 'Open','Save', .. would be buttons instead of a selectbox-list with an OK button (e.g. similar to Opera). For people (like me) who do not like the default selection (whatever it is), this saves one click and is much more 'robust' (if the buttons are always at the same position) because you do not need to hit a small radio-box (and to remember to do so!) but just a big button which always does the same thing.


However, I noticed that in the Options-dialog, some Content-Types are already based on extensions instead/in addition to 'application/whatever'. Setting the action to 'Save As' seems to work for me, but if set to 'Always ask', the 'Always perform this action' option is still disabled (which I would simply call a UI bug).
Keywords: ux-control
I'm not writing this as an opinion piece -- that would not belong here -- so let me state my problem as exactly as I can. 

Currently checking the box is a no-op under some well defined, common, and reproducible circumstances. 

Many users are surprised and annoyed by this behavior. IMNSHO the initial description of bug 331259 captured this quite well, but in search of an implementation, the bug drifted way off base. The bug this comment is attached to is apparently where the action has moved to, so this is why I'm writing it here.

----

Indicating an affordance with the UI, and then ignoring the action the user is lead to take -- without a reasonable explanation -- is a grave error in user design.

But, in trying to fix this with bug 331259, the focus shifted to a more technical interpretation and into RFC land. (I'm not trying to be disrespectful here. I have myself committed extensive specification nitpickery in various contexts for almost as good reasons as stated in bug 331259. Anybody who groks RFC 2183 has nothing by my respect and thanks.)

Unfortunately, the difference between the nitpicking of the RFC divinations and the more fundamental problem of user confusion is hard to see when you are a mere mortal. 

Us mortals just experience a consistent FAIL when we try something again, and again, and again. And when the browser just keeps encouraging us to try it one more time, while still ignoring our actions, we get frustrated. 

I'm not saying that the RFC interpretations are not correct, nor do I say that the RFC isn't saying this for some very very good reasons (such as "failure to follow RFC xxx causes p0wnage"), nor do I say that the people who are fighting to have the RFC's obscure dicta strictly followed are not doing the right thing, nor do I say the the fix must be that we bypass/ignore/re-interpret some aspect of some RFCs.

What I am saying is that if it doesn't fix the problem as it is seen by the user, then it isn't the fix for what the user is complaining about.

The original bug reported that a user's action was ignored and the user was left confused. The user is still left confused after bug 331259 has been "fixed", verified, and closed.

_That_ is the problem.

My hope is that this time somebody will look at the deeper problem of eliminating the user confusion before closing the bug.

I'll be happy even if it involves something as crude as a dialog explaining the problems and risks and explicitly asking "is _really_ what you want?" (and I _do_ hope there is a better way), or as sophisticated as reformulating the question such that the issue doesn't arise in the first place. 

Just don't claim the bug ("confused user when xxx") is fixed when seen from a particular narrow technical viewpoint, _however correct that viewpoint is_.

BTW, the most dangerous outcome here is not that some obscure RFC clause gets ignored or misinterpreted, but that it so much easier (and way way faster) to write an add-on that completely ignores the whole shebang and opens a big security hole as it just makes a complete bypass of it all.

I don't think anybody here wants such an add-on -- or even worse -- have it become popular.
Is this bug still open? I'm using 3.6.11 and it's extremely frustrating. I've started to use Chrome since it's much easier with opening files automatically.

Does anyone know of any Add-on that might assist with this issue. Thanks.

If this problem isn't fixed by the release of Firefox 4. I'm definitely moving on to Chrome.
There is add-on solving this problem for .torrent files made by Russian developers but it also creates new problem - inability to work with downloaded .torrent files in any other way.
http://forum.mozilla-russia.org/viewtopic.php?id=39820
Thanks. However, this doesn't deal with the underlying issue. I think I'm just going to move to chrome. Much more development going on, unlike Firefox which has a major bug for several years already, and hasn't been fixed.

Thanks for the advice though.
FlashGot seems to work with most files -- http://flashgot.net/
Back in the real world of people using their computers to download files, I get asked ALL the time why they have to click so many times to do something that appears to be so simple, and yet it's not.

These are the people who've embraced Firefox after deserting IE (on my advice) and now they get hit with this inane constant prompting.

Please either implement some kind of config setting (modified in about:config) if at all possible. I simply don't have the time to discuss the merits of various RFCs. I want my PC to be useful and assist me, not hassle me all the time. If I was to inform any of the people I deal with about dear Boris and his RFC ramblings, then I would be met with a blank look/confusion.

Multiply my frustration by a factor of all the other pro-posters here and I think you'll perhaps understand.
(In reply to comment #69)

Seconded
By the looks of it, Boris has left the building long time ago and is not following the discussion, just like any other mozilla developers (if there were any inthe first place). The only emails are on the CC list are probably of those who would like this issue to be solved. It also seems that there is no opposition to the changes proposed - the problem is that there is nobody ABLE AND WILLING to implement these changes. And as long as this issue is lost within this huge mozilla bugzilla swamp nothing will happen. Nobody and i mean ALMOST NOBODY knows about this little dungeon of despair. Mozilla bugzilla is very helpful to developers and sometimes users in many aspects but it is far from perfect and in this case IT DOES NOT WORK. 

A call to arms :)

I suggest setting up a webpage/blog outside of confines of this environment and use it raise the awareness of this issue. And i mean a real viral action. Something that can be actually be heard by those who CAN and motivate them to DO. I believe that we can encourage someone to do something about it especially if there is a publicly visible reward in the end to the hero programmer that had actually done it. and i am not talking about money - although that could be part of the campaign. but gratitude of all the thousands that we can make to sigh up a petition of a kind or something like that could mean a lot too.

I have difficulty expressing all the possible ways to market this project but i believe it can be a lot of FUN!!! 

I am talking about posting pictures of how this can be done, making Camtasia video's of current situations and how it should work and posting them on youtube. I am talking about creating a facebook page and placing those vids there and on the blog page. Getting people to "Like it" that facebook page and have this discussion in the open. We could have some fun playing with SEO and try and get this issue high in google and youtube ranking so that anyone typing "firefox problem" in google will see this issue and words like "stupidest firefox usability flaw" associated with it. We can make a lot of constructive  fun of Mozzila in any way imaginable :)

I am very busy with starting my own business and all the research i have done on marketing my upcoming business served as inspiration to write all of the stuff above. I would love to organize this thing but i will have my hands and head full coming months... Yet i will definitely actively participate and collaborate with anyone willing to do it together.  

I have created a blog http://dothisautomatically.wordpress.com/ but www.dothisautomatically.com is available so if any of you want go for it ...

If any of you would like to have some fun instead of waiting for some lost developer to blunder unto this unglorifying bug let me know
I don't think it will be lost. I continue to advocate for this issue. Set up your viral site and have fun, if you must, but feels like a waste of time and a presumption of intent based on facts not in evidence.

We should do this. Simple as that. We shouldn't base our browser's behaviour on an RFC intended for a mail client.
(In reply to comment #72)

> I don't think it will be lost. 
Hi Mike, i am not sure what you mean by this.

> I continue to advocate for this issue. 
I do continue to advocate for this issue as well. Unfortunately just advocating does not seem like getting us anywhere. This bug report was created 2 years ago and there is no one who came forward and said "I'll do it!" 

> Set up your viral site and have fun, if you must, 
I just have: http://www.dothisautomatically.com

> but feels like a waste of time 
it's quite possible that it will be a waste of time. On the other hand it might not... and it sure beats all the animo that comes from mozilla team. I give no guarantees that i will pull this through... BUT I'll try and hopefully get some some collaborators

>and a presumption of intent based on facts not in evidence.
You lost me here - which intent did i mistakenly presume?

> We should do this. Simple as that. We shouldn't base our browser's 
> behaviour on an RFC intended for a mail client.
From your mouth to mozilla gods ear :) Could not agree with you more!!! But who are those "We" you are talking about?
This drives me up the wall :(
Love Firefox, hate clicking.
(In reply to comment #73)
> > We should do this. Simple as that. We shouldn't base our browser's 
> > behaviour on an RFC intended for a mail client.
> From your mouth to mozilla gods ear :) Could not agree with you more!!! But who
> are those "We" you are talking about?
"Mike Beltzner is the Mise en Scène for Firefox: a product manager and director of sorts, setting direction and guidance for the delivery of Firefox to its millions of users worldwide." from https://wiki.mozilla.org/User:Beltzner
I'd say he's talking to/about all the Firefox devs :)
This drives me crazy too.  so much clicking, so little reward.  Please fix, patch or give us the option to hard code actions to filename extensions.
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.
(In reply to comment #78)
> 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.

A nice find, thanks.
A proper fix is long overdue though!
Very cool, I'll have to try it out.

Everyday, I click the sad smiley in FF4 Beta and leave a comment regarding the fact that even in the beta for the next version this STILL isn't fixed.  I encourage everyone here to do the same. =)
Also consider voting for this bug (at the top of this web page).


(In reply to comment #78)
> it yet, but a clever guy from Russia made a Firefox add-on that provides this
> much needed functionality:
With a workaround in an add-on, the probability of a fix is even lower now. :-(
About the drive-by attack argument:
To circumvent this "protection", the attacker must just not use the "content-disposition: attachment" header? Is that correct?
Give up. This bug has been in every version of Firefox since the beginning. It's still in the latest 4x builds too. No one cares. No one is even making an attempt to fix it. It was reported years ago, and still no one cares. It isn't going to be changed.
Firefox is dead. Just use Chrome. It's better in every single aspect. Much more development and dedication to user experience.

I must say that I started using Chrome due to this specific reason. I needed it for work, and every time it would ask me which program to use instead of doing it automatically. This single reason alone, drove me to use Chrome. I haven't looked back since.

Hope this helps anyone looking for a fix.
Firefox is dead. Just use Chrome. It's better in every single aspect. Much more development and dedication to user experience.

I must say that I started using Chrome due to this specific reason. I needed it for work, and every time it would ask me which program to use instead of doing it automatically. This single reason alone, drove me to use Chrome. I haven't looked back since.

Hope this helps anyone looking for a fix.
(In reply to comment #82)
> To circumvent this "protection", the attacker must just not use the
> "content-disposition: attachment" header? Is that correct?
I think we've been through this: Firefox can and should differentiate between downloads triggered by user clicking on a link and "automated" downloads.

(In reply to comment #83)
> Give up. This bug has been in every version of Firefox since the beginning.
> It's still in the latest 4x builds too. No one cares. No one is even making an
> attempt to fix it. It was reported years ago, and still no one cares. It isn't
> going to be changed.
Because until short ago it was reported in bugzilla.mozilla only and out of millions of people who knownly or unknowingly suffer from this nonsense only a few dozens found their way into this dungeon. This is a place to help developers to funnel bugs, that's it! There is little you can do here if there is indifference or outright unwillingness to fix something. 

This mailing list is a medium from a year 2000. Things like blogs and social media have arisen since than. I believe this entire thread would have more impact if it took place on the blog page i've mentioned (or a dedicated Fzcebook Community page). If all 64 current thread followers (min a couple of Mizzila devs) were to click on "Like it", at least a couple of thousands of friends would see it, with a few chain reactions. Every time one of you posted a message, again another couple of thousands. Even reactions like "Just use Chrome" would be seen by a couple of thousands every time, instead of 60 FF addicts. That might make FF people take this more seriously. A Facebook App could be made "Tired of this weird Firefox behavior? Click here to send a complaint to Firefox team!".

Of course another idea is to tell Google team to advertise their browser on Torrent sites and tell everyone why in this particular case Chrome is better.
(In reply to comment #72)
> We should do this. Simple as that. We shouldn't base our browser's behaviour on
> an RFC intended for a mail client.

Mike, obviously you are on our side on this issue. And as you said, you would advocate fixing this within FF dev team. Have you tried? What were the results? Could you, as "the Mise en Scène for Firefox: a product manager and director of sorts, setting direction and guidance for the delivery of Firefox to its millions of users worldwide", give us some more insider information on why nothing has been done? Is it shortage of developers? is it because this usability flaw has low priority? is it lack of agreement that this "bug" is a bag at all? Any other reasons? 

Talk to us, man!
You had me up until all that stuff about citizen advocacy. I agree the devs themselves (or no one) will fix this though. After nearly 3 years of complete inaction I wouldn't hold out much hope however.

Even if they didn't change it to allow user selected actions to be remembered the dialogue should at least be changed to something that makes more sense. Offering to remember an action and to repeat that action for specific filetypes 'from now on' and then not doing it, just doesn't make any sense. I know there is an argument about the security issues this presents (although this has been proved baseless above), however if other browser can handle this action without difficulty then why not FF? 

I suppose this is what happens when you have 'design by committee'. Stupid bugs (and bureaucracy) emerge and become so intractable (due to so many conflicting perspectives) that it becomes almost impossible to fix them. This is why Soviet era cars were always so poorly designed too.

PS

I'm unsubscribing from this debate. I think waiting over 2 years for a fix is probably long enough.
(In reply to comment #88)
> After nearly 3 years of complete inaction

My understanding is that this has been a known issue for much much longer than that, but other older bugs have been closed as a duplicate of this. See e.g. bug 331259, shamefully closed as "VERIFIED FIXED".
Way back up in comment 1, kevin pointed out that bugzilla is not a discussion forum and he was right. This bug doesn't need advocacy, or calendar counting, or threats to move to other browsers, or righteously indignant demands, or consensus building, or massive grassroots whatever the hell.

It needs a patch.

That it hasn't gotten one from someone on my team yet is purely a function of them having too much other work to do. Anyone in the 89 comments above this one is, of course, welcome and invited to attach one - we'd love to fix this bug. Anyone up for it?
That is pretty dismissive of users opinions dude. How else are ordinary users supposed to bring glaring bugs like this to developers attention?

I agree threats to move to other browsers, or starting grass roots campaigns, or whatever else method of drum banging is used a a bit childish and pointless. But what you are dealing with here is ordinary users, so taking a typically elitist developers stand and telling ordinary users to go fix it themselves probably isn't all that helpful.

I'm sure if everyone in the world could write code, then someone would have fixed this by now - but that's why people in the world are divided into different specialities and different professions.

The only hope ordinary users have is to try to keep issues like this alive and keep brining them to developer's attention until someone decides to fix them. Otherwise what's to say someone won't just come along and randomly (as has happened in the past) mark the issue as 'fixed.'

Anyway I really am unsubscribing, just as soon as I can work out how to unsubscribe from a specific thread. Not because of some childish tantrum, but because I have simply lost interest (and hope) of the issue ever being fixed. I stayed quiet and watched this thread for well in excess of two years. I am I regret simply tired of reading about it now.
Because this bug report is still open and bug #331259 was marked as Closed/Fixed, I marked bug #331259 as a duplicate of this one.  

I must note that the overall problem was reported in bug #331259 on 21 March 2006, 2-1/2 years before this bug report was submitted.  Everyone should realize that this problem has been known for almost five years.
(In reply to comment #93)
> Everyone should realize that this problem has been known for almost five years.
You were already told off for altering the other bug wrongly, but I'll point out that this was known about in bug 285976, six years ago. That's the bug that would disable the "Do this automatically" checkbox so you can't tick it in the Content-disposition: attachment case, including an explanation. The usage of that HTTP header has changed since then to be in far wider use which is why this bug was reopened.
(In reply to comment #94)
> I'll point out that this was known about in bug 285976, six years ago.
Correcting myself, the original report was bug 236541, seven years ago, dealing only with remembering the "download" action, this bug is for the "open with" action.
I've made an extension that fix this bug:
https://addons.mozilla.org/en-US/firefox/addon/do-this-automatically-modif/
It doesn't work in FF4. Besides although possibly useful, extensions don't fix bugs that should probably be fixed anyway.
(In reply to comment #97)
> It doesn't work in FF4. Besides although possibly useful, extensions don't fix
> bugs that should probably be fixed anyway.

Works great in Firefox 4,The above is incorrect.
Thanks for that!
Not in Beta 12.
Besides it really is worth remembering that this is a work around and not a fix. It may even have the effect of removing any motivation there may have been (although there doesn't appear to be much) of fixing this bug to begin with.
(In reply to comment #99)
> Not in Beta 12.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre

;)
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.
For the life of me, I cannot find where to change an attachment from OpenOffice to MS Word. It just automatically wants to use O.O.
Voting...
(In reply to comment #103)
> For the life of me, I cannot find where to change an attachment from OpenOffice
> to MS Word. It just automatically wants to use O.O.
life of me, I cannot find where to change an attachment from OpenOffice
> to MS Word. It just automatically wants to use O.O.

This isn't anything to do with this bug. This isn't even a bug. This is down to your own lack of knowledge. The best place to resolve this is either via Google (probably quicker) or the Firefox MozillaZine forums. http://forums.mozillazine.org/viewforum.php?f=38
Regrouping:

The issue represented by this problem report is that when we see a file served with content-disposition: attachment we always ask the user if they want to save it or open in a helper app instead of just automatically handing to the helper app (as we would for a MIME type served without content-disposition: attachment).

Bug 470332 was meant to ameliorate the situation by remembering the list of helper-apps in the drop-down; I can report that although it's marked as FIXED, it doesn't always work. Presumably that's because sometimes we just can't actually remember it (as no MIME type given, I suppose?). In those cases bug 285976 was meant to not show the "always do this" UI, which would be only slightly less frustrating (in that we wouldn't be promising to do something we couldn't) but doesn't really fix the issue.

Further, in comment 4 and comment 40, Jesse argues that this header is often used as a way of providing additional security by not inheriting the origin of the referring website; our poor user experience from that choice is problematic.

I believe that Firefox should simply ignore content-disposition: attachment; the number of cases where it's being used properly (to encourage someone to download the file because helper apps may not allow saving) is, in my experience, vastly outweighed by the number of poor user experiences it creates ("I clicked on this file and Firefox didn't just open it in whatever"). We're also somewhat unique in our handling of the header, meaning that Firefox "seems" broken to people although by the very strictest letter of the RFCs, we're doing the right thing.

Perhaps in the fullness of time it will be easy to also add an infobar or prompt that asks users if they also wanted to just save the file, but for now, I think people will be able to find their way to right-click and "Save As..."

(NOTE: Please do *not* add advocacy comments to this already busy bug. If you agree, that's great, be quiet. If you disagree, and have an alternative proposal or factual clarifications, feel free to add a comment)
URL: http://www.dothisautomatically.com
[quote]by the very strictest letter of the RFCs, we're doing the right thing[/quote] 

As per comment 22, the RFC in question is only meant to apply to mail programs.  Firefox is adhering to an RFC that it shouldn't.
So if I understand this correctly, the content-disposition header is only relevant if the user would normally want open the file automatically? 
In that case, if the user has selected 'Save As' as default action, there is no need to show the dialog, only if the user has selected 'Open with'. The 'always do this' checkbox could be disabled only for the 'Open with' selection, if the dialog is shown for a download with a content-disposition header.

One problem is that the behaviour is not transparent to the user, because he does not know that the server sent that header / requested to save the file, hence it looks like a bug. So displaying something like a yellow infobar-like box (to draw the attention of of the user without looking like a warning/error) with a text like 'The server encourages you to save the file' instead of the disabled 'always do this' checkbox could go a long way regarding user experience, ideally including a check/select/radio-box 'Always ignore what [a|this] server wants [for this file type]' (and only if Open With is selected if content-disposition is ignored when 'Save As' is the default action).

I would be willing to write a patch for this (provided I find the time), but I would like to make sure that it has some chance of being accepted first ..
(In reply to comment #109)
Apologies, comment 109 should have stated comment 72 as it's reference not 22.

I very much like the idea behind comment 110 but would expand upon it slightly.  Use a bar akin to remember password. Allow the user to save a default action and should action be anything other than "Save as..." a bar come across indicating possible actions.

If the action is anything other than save as a simple bit of text akin to comment 110:

"The server [insert domain] recommends saving this file, your default action is [insert default action].

Along with buttons:  "Save as...", "Change action", "Dismiss"
Dismiss = close message continue action
Save as = open save as dialog box
Change action = open dialog for selecting a one time action with an option to make it the default action, take the new action

In doing so it should not attempt to stop or delay the execution of the default action.  Akin to if you click a link the browser continues to load until given new instructions.  This then has the added benefit of being able to open and save a document simultaneously.
For users still annoyed by this bug, I would like to point out a workaround is available in the form of the InlineDisposition extension. It works like a charm, and much better than the old Do This Automatically extension.

https://addons.mozilla.org/firefox/addon/inlinedisposition/
Per addons.mozilla.org, the InlineDisposition extension is not compatible with SeaMonkey 2.2.  Although I might be able to tweak its install.rdf file to make it compatible, this clearly illustrates why extensions are merely workarounds for bugs and not solutions.
I'm writing this using Chrome. I finally switched yesterday, after years of using Firefox. This bug is the reason.
I think that request bug 801786 is not a duplicate of request bug 453455.

Request bug 453455 is about making Firefox remember the user choice in case of an "attachment" header sent by the server.

In request bug 801786, I explain that the choice I want is missing. So this request is not about remembering the user choice, it is about offering to the user the choice which is currently missing.
it does this with .torrent files too...
Whiteboard: [p-chrome] [sg:want] → [p-chrome] [sg:want] [Advo]
I think that constant referencing to RFC is incorrect approach to this problem.
Yes, browser should adhere to RFC and it is good thing. That's why FF should popup "Opening" dialog by default for any file that is marked as "attachment".

But it must be up to user to be able to override this behavior. I don't understand why drag for years this argument for feature that is obviously should be given at user's decision! If I deliberately mark some file type to be opened automatically - why FireFox decides that for me? Why it assumes that it "knows better"? Aren't we all tired of Microsoft's strategy "we know better than you what you need"? Flexibility was always strength of FireFox, why become stubborn on this feature?
If user wants to shoot himself in the leg (like I do) - please let him do it.
I use an extension Web page fixer. It is not ideal solution. Please just fix this bug.
text transfer from bug 57342:

i am using Waterfox 24.0 (64 bit build version of firefox) on Windows 7 x86 64 bits.

when visiting this page: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/1_10_00_23/index_FDS.html
(might require a free account to view or download)
and downloading the windows version (*.exe) of the file set
then i can select any option for opening or saving including the "remember my decision" option.

but when going for the linux version i only get offered two options: open with an application (default here is VLC) or download but the "remember" button is grayed out.

for my impression the browser should be able to remember decisions for explicitly html/mime tagged file formats as already realized. but for for non-tagged or "wildcard"-tagged files and it shall be check for the file name extension (or absence of such an extension - this happens more often than you would think) and decide based upon that extension. so the browser needs not only a mime type default action configuration database/listing but an extension based handling if mime type is not that useable. maybe even the user can pass down certain mime types to the extension based treatment. thus the mime type layer should see a new option: "handle by file extension".

@Sergio - thats a nice proposal in that area. i can support that. its all about options.

BTW i think the dialog does not mention the mime type so i am a bit lost in diagnostics for that my faulty cases using purely the browser. the dialog should mention the mime-type he asks me about.
(In reply to Alexander Stohr from comment #124)
> text transfer from bug 57342:

> for my impression the browser should be able to remember decisions for
> explicitly html/mime tagged file formats as already realized. but for for
> non-tagged or "wildcard"-tagged files and it shall be check for the file
> name extension (or absence of such an extension - this happens more often
> than you would think) and decide based upon that extension. so the browser
> needs not only a mime type default action configuration database/listing but
> an extension based handling if mime type is not that useable. maybe even the
> user can pass down certain mime types to the extension based treatment. thus
> the mime type layer should see a new option: "handle by file extension".

I think this is exactly what is needed.
I'm going nuts with PDFs that FF don't want to open with my (external) PDF-Reader anytime, just because of "something" (Mimetypes) that obviously are not suitable to recognize a PDF properly, what can by done by fileextension easily; I recognize the files and have to click open every time ...
an example is here: http://www.dandelon.com/servlet/download/attachments/dandelon/ids/FL001847F924468B0CB3CC12572670027878A.pdf
Blocks: 773942
Flags: firefox-backlog?
Flags: firefox-backlog?
Depends on: 1055623
Whiteboard: [p-chrome] [sg:want] [Advo] → [p-chrome] [sg:want] [Advo][qx]
Should this bug explicitly be marked as duplicate of older bug 236541? or the other way around?
(In reply to martin.monperrus from comment #137)
> Should this bug explicitly be marked as duplicate of older bug 236541? or
> the other way around?

Neither. Bug 236541 comment 38 restricts the patch to only the case when "save as" is the choice.
Hum, this subtlety isn't visible in the bug title:
"do this automatically for files like this" doesn't work when Content-Disposition:attachment is used
Make "do this automatically for files like this from now on" work even with "content-disposition: attachment"

According to your comment, I understand that "do this automatically for files like this" doesn't work only when "open with" is selected?
+1

In my case this is the behavior you described: "do this automatically for files like this" doesn't work ONLY when both are true "open with" is selected and "content-disposition: attachment".

Developers, please finally solve this big problem. She is in the open state for 11 years. Google Chrome has no such problems, I really want that in Firefox there is no problem in this direction. I want a comfortable use.

I'm going to try to summarize the problem here as I see it.

Over the last few years, Mozilla has moved in the direction of focusing on security at the cost of some user control. Though to my knowledge no official statement has ever been made acknowledging this, it is apparent through their actions and the tone of some of the things they have said. This is not the place to debate that decision, and I do not wish to, but for our purposes it suffices to note that there is inherent tension between those two aims. Any power the user is given to alter the behaviour of the browser's interaction with external content, risks creating a security vulnerability. Most users do not have a strong grasp of security theory, and rely heavily on Mozilla's experts to keep them safe.

There is an inherent risk in having an external application automatically process any kind of file. Many common programs are not designed to handle malicious input, and some that are do a poor job at it. Glances towards Adobe Acrobat. It is a sane default to ask the user before proceeding any time there is an elevated risk of bad behaviour. Since it appears from a quick search that a number of server operators use content-disposition: attachment on user-uploaded files to reduce the risk of XSS-type attacks, it appears we have such a case. Thus, a credible argument can be made that Firefox ought to ignore the user's choice of automatic behaviour in these instances. That other browsers do not react this way does not constrain us. We are not obligated to emulate their design decisions.

It has been suggested in comment 90 that people out to do less talking and more patch submitting, but as comment 110 noted, people are reluctant to work on creating a patch when they are uncertain if it has any chance of being accepted due to design choices by the development team. I strongly suggest that a Mozilla staff member make an executive decision as to whether this behaviour is in fact a bug to be fixed, and state so in a comment, or else close this as WONTFIX and say that a decision has been made to err on the side of security and not let the end user select a default behaviour when a content-disposition: attachment exists

Flags: needinfo?(mak77)

After 11 years - more and more clarity develops on this issue.

Please consider USER INTENT as an important aspect in the early design and later - policy implementation of this "feature". Now it is known how important (forced) user security is regarding XSS-type attacks, we have BOTH SIDES of the issue exposed. Seems like, the solution involves a little more programming, not merely "turning off" security concerns.

I'm probably typical in my INTENT. I have repetitive tasks where I download CSS files from trusted sources, format them, and archive them.

On selection of "do this automatically for files like this from now on" Firefox can throw a (severe) user warning about XSS-type attacks, then offer to allow the recurrent behavior, explicitly for the chosen server, forevermore. User has been WARNED, has actively chosen to do the deed with THIS SERVER ONLY, and has exonerated Firefox while maintaining the personal freedoms we expect using personal computers. Of course, removal of the "user approval for the site" must also be programmed.

For examples of WARN but "DO if approved by user" - look no further than Windows.

even a trusted site can be compromized at some point in time.

nothing against rarely requested features and nothing against support for legacy items.
thats about free software: having the ability to do so.
putting a fence in place with a clear explanation why its not recommended to use that is fine.

maybe adding a monthly security report will help people checking and re-thinking their special settings.

There's too many proposals and opinions here to be able to make a choice that will satisfy everyone.
There are 2 possible ways out, that I see, that are not exclusive:

  1. hide the "Remember my choice" checkbox when it can't be respected. While this doesn't solve the problem (it hides it under the carpet), it would be less surprising and infuriating for the user. This is pretty much bug 285976, afaict. I think it'd be a safe thing to do regardless and wouldn't prevent future and better fixes.
  2. Just let the user action go through, that is basically what the other browsers are doing (at least Chrome, I just tried through this test page: http://demo.borland.com/testsite/download_testpage.php) . The fact is this solution is a lot more complex and thus will require more time, because someone with a good grasp about the security implications here should make a call. That's not me unfortunately.

I don't think we'd be adding a pref, a pref like this is the classical footgun, either this is a security risk or it is not, a pref doesn't solve that and can be easily under-evaluated.
I finally wonder if add-ons can work similarly to a pref for user willing this behavior, wouldn't something like https://addons.mozilla.org/en-US/firefox/addon/inlinedisposition-reloaded/ basically do what most are asking for? If an add-on could replace the request for a pref, it would pretty much solve 2 without exposing everyone to possible risks.

I know this is not a finalized answer, but the question was whether this is a wontfix. I don't think it is, it just needs some middle steps and investigation to figure out the actual risk, and why other browsers think that risk is moot.

Status: REOPENED → NEW
Points: --- → 8
Depends on: 285976

That addon just replaces the header of "content-disposition: attachment" to "content-disposition: inline". Despite the name "inline", any file types that are not handled by Firefox will be downloaded and opened. And it will actually respect "do this automatically" flag.

As you may already see (and mentioned by plenty of people above), this means that if a site really wants to do malicious things (by auto opening certain files), it can do already: just use "content-disposition: inline" as response header.

So in my opinion, disallowing "do this automatically" for "content-disposition: attachment" only is pointless even from a security perspective.

And of course, such addon will have side effect for file-types that can be opened both inline and or as attachment/download (like images that are supposed to be downloaded will now be opened in Firefox).

Flags: needinfo?(mak77)

For the record, addon "InlineDisposition (WebExtensions)" is still a valid workaround: https://addons.mozilla.org/en-US/firefox/addon/inlinedisposition-webexts/

An example of a PDF with Content-Disposition: attachment

URL: http://www.dothisautomatically.com → https://www.seattlesymphony.org/~/med...

(In reply to monperrus from comment #150)

For the record, addon "InlineDisposition (WebExtensions)" is still a valid workaround: https://addons.mozilla.org/en-US/firefox/addon/inlinedisposition-webexts/

InlineDispotition didn't work for me, but the more recent Display Inline one worked (https://addons.mozilla.org/en-GB/firefox/addon/display-inline/)

Programmers of FireFox should finally do something about this. Since years during each download I am offered this checkbox "Do this automatically for files like this from now on." and never, ever is anything done in the way as my checked checkbox would indicate. If this bug, I consider this clearly as a bug, is indeed related to bug 285976, then it would indeed be time to address this. IMHO this gets close to effrontery to offer that checkbox since years and never honoring it in any way, not even with a warning that it will not be respected. Very, very poor programming. The fix suggested in the discussions of bug 285976, i.e. hiding that checkbox, would for me and all other confused users probably be an acceptable alternative to an actual implementation of the handling of the downloads as offered via this checkbox. It is time to act and hide this confusing checkbox I believe.

Why is it necessary to avoid fixing this rather than a band-aid solution?

This used to work just fine under at least FF 48 and slightly newer, which was not that long ago.

@ smayer97: Of course fixing this would be much better. But I have given up hope. As you can see this bug is with us since 13 years! The same is the case for numerous bugs related to downloading (not only Firefox also Thunderbird, causing me to totally stop using Thunderbird) . As a programmer I have provided detailed solution suggestions considering all aspects. It was never picked up. So I have given up trying to help and have given up to expect anything. Perhaps for band-aid I still dare to hope for. ;-)

(In reply to andreas.fischlin from comment #166)

BTW, I am a programmer myself. I know this can't be a big deal to outcomment the display of this checkbox. ;-)

As a programmer yourself, it can't be such a big deal for you to submit a patch that does exactly this. This would certainly be a more collegial and productive course of action than publically berating others for what you consider to be "very poor programming".

@Tristan Miller: You are right, that may be a better contribution. However, I cannot afford to participate in the development of all software I am using and need to focus on the ones I am really responsible for. And I also believe that programing does not consist of only adding patches, but good design requires familiarity with a software product, and I am lacking all this in the case of Firefox. I think my decision to abstain in this case is the right one. Given all this, I am afraid, my verdict remains: Keeping a bug (and with it many related ones) open for 13 years that confuses every user of Firefox (and AFAIK also Thunderbird) repeatedly since years is IMHO not representative of good programing. P.S.: And I provided very detailed suggestions how to handle downloading, including graphical designs for alerts to the last letter, yet all this was ignored. I am sorry, this did also not invite me to continue to participate in the development. I hope you can understand that also a bit.

@Tristan Miller: As you seem to be a programmer of Firefox: Many, many thanks. I like otherwise Firefox and I am generally very happy about it. So, indeed many, no a thousand thanks!!!!!

(In reply to Tristan Miller from comment #169)

As a programmer yourself, it can't be such a big deal for you to submit a patch that does exactly this. This would certainly be a more collegial and productive course of action than publically berating others for what you consider to be "very poor programming".

They simply laid out their view on the current state (well, continuous for years) of this matter, and were honest... There wasn't attacking of people or calling names. I'm sorry you were offended by that. You most likely concur with the sentiment that this part of the application and it remaining as it is for long are both not good... I don't think it's a reasonable expectation that people will just hide it or lie about it while discussing it.
A patch submission doesn't preclude accompanying discussion anyway, but I think it's also disingenuous to call it more productive... unfortunately we know that even if patches were offered even years ago, as previously discussed here, it doesn't mean that they would have been used or made a difference in the issue. In the first place this issue isn't one where implementation details are complex, unknown or time consuming to write. It is pretty clear that it is one of those where there just hasn't been a decision by Mozilla to fix it, or to apply the band-aid solution, and that decision is the only thing that is missing (indeed I expect it would take a programmer with experience with contributing to the project a couple of minutes to handle the implementation). Yeah, that's a kind of thing that unfortunately doesn't exactly invite people to contribute to the project in general.

(In reply to vagmer from comment #172)

A patch submission doesn't preclude accompanying discussion anyway

If someone submits a patch or other new, concrete information that will lead to a fix, then let's discuss it here. Until then, please see Comment 1 (though note that the specific venues mentioned there have recently moved).

This is really annoying when you want to view several PDFs from a webpage in Firefox ,but the "choose action" pop-up gets in the way repeatedly even though it is clear I want to view the PDF files in Firefox without opening a separate application for it.

They have not decided if this is a bug or not? It worked fine for me in TB 6x.x and TB 7x.x and now is broken in TB 91.0. Thunderbird is not honoring it's own setting. How can this not be a bug? This is a 13 year old bug. My problem just started. Something obviously changed in TB 91.0. Please fix this bug. It is very annoying.

But the problem was just introduced in TB 91.0 for me. It has worked correctly for at least 10 years.

If they have decided that this problem won't be fixed then why even offer the option "Do this automatically for files like this from now on." if it isn't going to work?

What is hard to understand is the following:

  • this was never a problem (for me) prior to v57 of FF, as early as v16, which is only 6 years old, so not sure why this is a 13 yr old bug. Then again, I was running it on Mac OS X 10.6.8 until then, so is this an OS dependent issue?

  • what is so hard to get this fixed? Isn't it simply to save the option selected then read it when downloading? How complicated can this be? Especially since the algorithm for this already exists in older versions.... just copy the design, no?

Whiteboard: [p-chrome] [sg:want] [Advo][qx] → [p-chrome] [sg:want] [Advo] [qx] [fidefe-Outreachy2021]

(In reply to smayer97 from comment #186)

What is hard to understand is the following:

  • this was never a problem (for me) prior to v57 of FF, as early as v16, which is only 6 years old, so not sure why this is a 13 yr old bug. Then again, I was running it on Mac OS X 10.6.8 until then, so is this an OS dependent issue?

  • what is so hard to get this fixed? Isn't it simply to save the option selected then read it when downloading? How complicated can this be? Especially since the algorithm for this already exists in older versions.... just copy the design, no?

No, this has nothing to do with the OS. This is a problem within the application only. And sorry, I am not going to describe the reasons for that once again. I have provided all details including several solution suggestions many years ago and I am now tired of these discussions going often in circles instead of resolving the issue(s).

I am not sure we understand each other well. The first issue is that the download folder is not separate from the folder where FF downloads files such as PDFs to when you want to look at that file within FF. The first folder should be the download folder, which the user can set to her wishes via preference setting. The 2nd folder should be a temporary folder, where FF stores those files the user just wants to look at using the browser and that folder ought to be under any Unix system a temporary folder, e.g. in /private/tmp. As I do not want the 2nd use to clutter up my actual downloads folder, I have set as the FF download folder a temporary foler in /private/tmp. Any true download has then to be retrieved from there manually. That is the first problem with FF, never addressed really, never resolved I believe since 13 years if I am not mistaken. The 2nd problem associated with truly downloading files only is the fact that FF did not honor the checkbox "Do this automatically for files like this from now on." when downloading some file type, e.g. a PDF and chosing some application by which to open it. Checking that checkbox never had an effect and FF continued for years to ignore the users choice.

My take on this is that FF should distinguish the two folders used for only looking at a file, e.g. a PDF from within FF, or actually downloading, i.e. truly downloading a file.

The 2nd fix would be to either hide a not functioning checkbox or then implement the feature the checkbox is offering.

(In reply to NolanK from comment #193)

Just to set the record straight: The fork you mentioned did NOT fix this bug. If fixed bug 1690395 with the (hacky) fix suggested in bug 1690395 comment #13. We agree 100% with the statement from bug 1690395 comment #31.

Not sure why all Thunderbird related bug reports are dumped into this Firefox bug.
Firefox and Thunderbird have wildly different use case. While "remembering with which app to open certain files" isn't much of an issue for Firefox, it's big issue in Thunderbird when handling lots of email with attachments.

Like some users before me, I suggest decoupling Thunderbird issue from Firefox and fixing it (hacky or not) on Thunderbird side, while leaving Mozilla to decide whatever think it's best for Firefox. If Mozilla fixes Firefox eventually, TB fix can be reverted.

As far as I can see, there is currently 3 TB bugs reported in last month for this exact issue, all marked as duplicate of this bug, which means users are reacting to it.

(In reply to Mihovil Stanic [:Mikeyy - L10n HR] from comment #197)

Not sure why all Thunderbird related bug reports are dumped into this Firefox bug.
Firefox and Thunderbird have wildly different use case. While "remembering with which app to open certain files" isn't much of an issue for Firefox, it's big issue in Thunderbird when handling lots of email with attachments.

Like some users before me, I suggest decoupling Thunderbird issue from Firefox and fixing it (hacky or not) on Thunderbird side, while leaving Mozilla to decide whatever think it's best for Firefox. If Mozilla fixes Firefox eventually, TB fix can be reverted.

As far as I can see, there is currently 3 TB bugs reported in last month for this exact issue, all marked as duplicate of this bug, which means users are reacting to it.

As FF and TB were made similar in terms of the code that is of relevance here, I am not convinced that a separate handling of the two applications is doable. I say this also, as this decision to use common code may be entrenched into the code maintenance too much to be sensible. But this is to decide by the programmers of these applications, not me (I progam other things).

Moreover, the user experience is basically the same. There are needs to view attachments and there are true downloads in both applications and from the perspective of the user experience I argue that it makes a lot of sense to treat them in the same manner, i.e. not only common code is less to maintain, but also handling the same user experience in the same way is only beneficial to all when based on a good user model.

However, there seems to be no solid user model for how to handle files, i.e. attachments in case of TB and linked files in case of FF. The problem is that the programmers seem not to understand the issues that users of the applications are confronted with and AFAIK there was never a proper treatment of these issues done. E.g. first there is the common problem of the inability of separating the viewing of attachments (TB) or linked files (FF) from actual downloading when a user wishes to keep those files on her system. Admitted, this has little to do with this bug, yet it relates to the same irritating decisions of the programmers what the user experience ought to be when users access attachments (TB) or linked files (FF). The 2nd problem, this very bug we discuss here, is then also not handled properly since years, as user experience seems here not to matter much. I have to admit, for reasons that escape me as e.g. FF is otherwise a wonderful application in many respects. But the issues related to the user experience in terms of how attachments are handled may indeed matter more in the case of TB. I for instance no longer use TB for exactly these reasons. In this respect I agree with you.

We've hit 200 comments here and the vast majority of recent comments are arguing about exactly how dumb Firefox programmers like me are for not having fixed it yet, so I'm locking comments as there seems to be little point.

We are actively working on a fix, but as several comments here have already pointed out, it isn't trivial and will come with some side-effects to 20-odd year old ways that Firefox has done downloads. The root cause of this issue is outlined in comment #22: avoiding dataloss when applications don't provide the user with control over the resulting file, while the file is stored ephemerally (ie in the temp folder) and gets deleted later. We'll update this bug when we're confident about those changes making their way to release.

Restrict Comments: true
See Also: https://mozilla-hub.atlassian.net/browse/FIDEFE-1990 →
Whiteboard: [p-chrome] [sg:want] [Advo] [qx] [fidefe-Outreachy2021] → [p-chrome] [sg:want] [Advo] [qx] [fidefe-Outreachy2021]
Whiteboard: [p-chrome] [sg:want] [Advo] [qx] [fidefe-Outreachy2021] → [fidefe-Outreachy2021] [p-chrome] [sg:want] [Advo] [qx]
Blocks: 1690395

(In reply to Anje from comment #203)

there are going to be an increase in Thunderbird users

I can't comment on Thunderbird, and recommend you contact the Thunderbird devs through non-bugzilla channels (matrix or email is probably best). I believe that bug 1690395 was reopened and tracks the TB issue. I'm hopeful that the Firefox changes will help TB devs fix this, but TB is different enough that other/more work may be necessary. You should discuss that with the TB folks.

If someone is already working on this, it would be helpful to communicate this

I did communicate this, in comment #201, which you quoted and therefore must have read. I don't know why you didn't take my word for it. If you don't trust my bugzilla comments, then no other change I could make to this bug would convince you that work is ongoing, and the issue is with the lack of trust, not with whatever work we are doing.

I did not assign someone to this bug or set a release date because the fix for this bug is part of a bigger project. Although we have hopes about which release that change will ship in, we can't promise anything right now - it depends how long it takes to stabilize the changes in question. Downloads are complex and have a lot of edgecases. We're currently testing out these fixes on the Firefox nightly channel. In barely a week, nightly users have already found 10 or so new issues with it which will need addressing.

As a result, I also did not (and still do not) want to write down a version or release here, because inevitably that information may get outdated or superseded, and then users will just be more upset.

(I have been reluctant to share the other bug links because quite frankly, 200 comments on those bugs is not something that is going to help anyone, either. I've added one now, please do not deluge that one with comments instead; it won't help.)

outsider users are being polite in trying to explain how important this bug is

Being polite is necessary, but not sufficient reason for commenting on a bug. This is a bug tracker, in which developers track work, and it isn't a user complaints forum. Being asked several times a week "when is this going to be fixed", no matter how politely, only delays a release date for the actual fix. I restricted comments for exactly this reason. We're sorry this hasn't been fixed yet, we know this is important to users, and that is why we are working on it. No further comments stating how important it is or how terrible it is that this hasn't yet been fixed are necessary, nor indeed helpful, at this point.

Depends on: 1733587
No longer blocks: 773942
Depends on: 773942

The fix for this as far as Firefox is concerned is riding the trains with Firefox 97. Thunderbird ended up with their own fixes that made it to TB 96 and 91.4.1. Any remaining issues with either Firefox or Thunderbird should be filed separately at this point - reopening this 14-year-old bug isn't going to be useful.

Status: NEW → RESOLVED
Closed: 16 years ago → 2 years ago
status-firefox97: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
Blocks: 285976
No longer depends on: 285976
No longer blocks: 285976
No longer blocks: 1690395
Depends on: 1710941

This was fixed by bug 1710941 when browser.download.improvements_to_download_panel=true. That pref is enabled by default in Firefox 97 and later.

Blocks: 1733587
URL: https://www.seattlesymphony.org/~/med...
Severity: normal → --
Depends on: 236541
No longer depends on: 1733587
Whiteboard: [fidefe-Outreachy2021] [p-chrome] [sg:want] [Advo] [qx] → [fidefe-Outreachy2021] [p-chrome] [sg:want] [Advo] [qx] [fixed by bug 1710941]
Whiteboard: [fidefe-Outreachy2021] [p-chrome] [sg:want] [Advo] [qx] [fixed by bug 1710941] → [fidefe-Outreachy2021] [p-chrome] [sg:want] [Advo] [qx] [fixed by bug 1710941][adv-main97-]

The fix got postponed to 98 because of last-minute issues being discovered while it was on beta.

status-firefox97: fixed → disabled
status-firefox98: --- → fixed
Target Milestone: 97 Branch → 98 Branch
No longer blocks: 1733587
Depends on: 1733587
See Also: → 1690395
Component: Downloads API → File Handling
Product: Toolkit → Firefox
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: