285976 - consider making use of aReason argument of nsIHelperAppLauncherDialog::show

Status: RESOLVED WORKSFORME

(Toolkit :: Downloads API, defect)

Description

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

from bug 285517 comment 3:
>Also, note that I'm somewhat concerned by the current lack of checks of the
>"forced" boolean in the toolkit code.  I just tested, and it looks like it has
>the problem SeaMonkey used to -- allowing users to select "remember this choice"
>when it can't honor that request (because the core code will still pose the
>dialog the next time it hits a Content-Disposition header, no matter what the
>value of the "alwaysAsk" property in the MIME info).

(aReason used to be a boolean called aForced)

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Attachment: Start

This is basically attachment 126870 [details] [diff] [review] (bug 193698) and attachment 177050 [details] [diff] [review] (bug
285517) ported to Firefox, and preliminary tests show that it works OK.

One issue with this is that the Firefox dialog has no description text, so
users may be wondering why they can't check the "Always Remember" box.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Patch still applies (and works), though speccing out the UI as mentioned in comment #1 is kind of blocking further work.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Gavin, educate me briefly: why *wouldn't* a user be able to check the "Do this automatically for ..." checkbox? Or are you just saying that the dialog could use some general UI prettification (which isn't something I'd really disagree with ..)

Comment 4

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #3)
> Gavin, educate me briefly: why *wouldn't* a user be able to check the "Do this
> automatically for ..." checkbox? Or are you just saying that the dialog could
> use some general UI prettification (which isn't something I'd really disagree
> with ..)

Currently, selecting "always do this" when a file is sent with the "Content-disposition: attachment" header results in the value of the checkbox being ignored, since the header indicates that "[the content's] display should not be automatic, but contingent upon some further action of the user" [rfc 2183] and doing something automatically would violate that. This bug is about disabling the checkbox in that case, since it's basically non-functional. This would raise the problem I mention in comment #1 about people being confused as to why the checkbox is disabled in certain cases. SeaMonkey's dialog disables the checkbox correctly, but it has some explanatory text, while Firefox's dialog doesn't (you can use the URL in the URL field to test, it's a text file sent with content-disposition:attachment).

Bug 236541 is about handling that case better in general (allowing automatic saving, but not automatic displaying). If that one is fixed then the dialog (with or without the patch in this bug) would have to be revisited to enable the checkbox if "Save" is selected, but not "Open with", or something like that, which would probably end up being even harder to explain without thoroughly boring the user :). See also Boris' bug 236541 comment 38.

Comment 5

[Mike Connor [:mconnor]]

I would rather ignore a SHOULD in RFC 2183 and allow users to choose an automatic action, instead of forcing them to deal with a modal dialog every time someone uses the attachment disposition type.  If I want all files of a certain type to be downloaded, or opened in an external app, why would I want a dialog to confirm this every time?

I think there needs to be a way to allow the user to skip this dialog, even if that means fixing the core code to allow that.

Comment 6

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

I want to note that this does not necessarily require core changes, see bug 236541 comment 45. but yes, with core changes this might be easier.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #5)
> I would rather ignore a SHOULD in RFC 2183 and allow users to choose an
> automatic action, instead of forcing them to deal with a modal dialog every
> time someone uses the attachment disposition type.

If webmasters are sending that header, they have a good reason to do it, this is rarely something done accidentally. IE has the same behavior, minus the bogus checkbox. I think Boris' bug 236541 comment 40 outlines very well why it's important not to just ignore it. Again, I think solution #2 outlined by Boris in bug 236541 comment 38 (allow automatic saving, but not opening, if I understand correctly) is best, but all of this is kind of getting out of this bug's scope. This bug is about disabling a useless checkbox when appropriate, I don't think anyone is really against doing that.

> If I want all files of a certain type to be downloaded, or opened in an
> external app, why would I want a dialog to confirm this every time?

"Every time" is misleading, it would only be every time the webmaster explicitly asks for it by sending the file with the right header, something that I think is rare enough at the moment, and used purposefully.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> If I want all files of a certain type to be downloaded, or opened in an external
> app, why would I want a dialog to confirm this every time?

Because if the external app doesn't allow saving (which is true of a number of apps, including some PDF readers due to the security-type flags you can set on PDFs), and you have your settings to open in this external app every time, then you can't save the data.  If you don't want to put up a dialog, just do what IE does (last I checked) and immediately put up a filepicker as soon as you see the "content-disposition: attachment" header.  I figured it'd be nice to give users a choice instead of doing that.

Or you can do what you suggested, ignore the header altogether, and break compat with various US and state government web sites.  I really don't care so much anymore; I'm getting tired of having to repeat all this information in various bugs, e-mails, etc.  The next person who considers changing this code should maybe consider reading the CVS blame and the bug reports that caused us to write the code the way it is right now before just saying that the code should be changed.  Save all the rest of us time and all.

Comment 9

[Mike Connor [:mconnor]]

As I understand/envision it, this would only affect the action that occurs when you left-click, which would cover most cases (you can always right-click and choose Save As).  The multipart document case is something I admittedly haven't considered, which makes this possibly more complex, and I'll have to dig down on that further.

A thought that occurs to me, sight unseen of this type of UI, is that if you have a page that has an attachment component, showing UI to indicate that there is a downloadable attachment may be more useful than just throwing a modal dialog.  This is a similar behaviour to how many attachments in webmail/IMAP are handled, so it shouldn't be a difficult concept for users.

Comment 10

[Boris Zbarsky [:bzbarsky]]

> As I understand/envision it, this would only affect the action that occurs when
> you left-click

Or submit a form.

> you can always right-click and choose Save As

See above.

> and I'll have to dig down on that further.

Awesome.  For what it's worth, I'm happy to talk about what our UI here should be and how the back end can best support that; I just want to make sure we're keeping all our use cases in mind.

As a side note, I hear rumors there are cases when Firefox shows no filepicker; does it give any feedback at all that something's being downloaded in those cases?

Comment 11

[Ian Pottinger]

(In reply to comment #7)
> "Every time" is misleading, it would only be every time the webmaster
> explicitly asks for it by sending the file with the right header, something
> that I think is rare enough at the moment, and used purposefully.

Rare?  For me, this happen often and on many different sites.  Considering the growing number of dupes to bug 236541, I'm beginning to suspect that this bug is a red herring to some other more frequent bug.

It would be great to see this resolved so I can see whether the check box is disable, and thus assume a Content-Disposition header was sent, or enabled, meaning some other bug is at play.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Sites use Content-Disposition fairly often.  Like any time they want you to save whatever it is.

> so I can see whether the check box is disable, and thus assume a
> Content-Disposition header was sent

If you really need to check this for some site, just test in Seamonkey -- not only is the checkbox disabled there, but the dialog says WHY it came up.

Comment 13

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

er, is the dialog really modal in ffox?

Comment 14

[Mike Connor [:mconnor]]

(In reply to comment #10)
> As a side note, I hear rumors there are cases when Firefox shows no filepicker;
> does it give any feedback at all that something's being downloaded in those
> cases?

If the filepicker is not shown, the download manager appears and is focused.  If the dlmgr is open in the background, we use getAttention() to notify the user (via whatever method the window manager uses, so on WinXP Luna, the window goes orange in the tray, other OS/theme combos will yield different results).

Comment 15

[Boris Zbarsky [:bzbarsky]]

> If the filepicker is not shown, the download manager appears and is focused. 

Only if the file is above some minimum size, no?  At least I seem to recall something like that, but maybe we were just talking about doing that.  And the behavior may depend on the autoclose setting for the download manager, as I recall.

Comment 16

[Mike Connor [:mconnor]]

hmm, right, there's that case where the file is small enough to finish downloading before the dlmgr is trying to open.  I think currently that's for downloads < 1 sec, but doesn't work quite right due to some timing issue.

Comment 17

[Mike Connor [:mconnor]]

Of course, that's only really concerning from a security perspective if the download isn't user-initiated (script/headers/etc)

Comment 18

[Boris Zbarsky [:bzbarsky]]

The point is, that case results in 0 feedback to the user about something being downloaded, which is not really acceptable in the content-disposition cases, I think.

Comment 19

[Mike Connor [:mconnor]]

Really, I think auto-downloading needs to be addressed in a better way that's less obtrusive than a dialog, and I think there's a valid concern in automatically downloading content without user interaction.

Time for some OmniGraffle flowcharting fun, methinks!

Comment 20

[Phil Ringnalda (:philor)]

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

Comment 22

[cmtalbert]

Created a litmus case for this because a lot of people are hitting it.
https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=5265

Gavin: Is it ok to use your server there, or should we move that php script onto a different mozilla server.

The test case is not enabled yet as we have not decided how to resolve this bug, so no one will see it when they go to run it until we decide to enable it.

Comment 23

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #22)
> Gavin: Is it ok to use your server there, or should we move that php script
> onto a different mozilla server.

I certainly don't mind, and have no plans for changing that URL, but it might be more reliable on a mozilla server. Does Mozilla QA have a PHP- or Perl-enabled webserver that we could put the simple script on?

Comment 27

[Matthias Versen [:Matti]]

There is another forced save as dialog : If Gecko does content sniffing.
The checkbox is disabled but you get zero feedback why the dialog is forced and why the checkbox is disabled.

Comment 28

[alex.a]

Ok, I'm not a programmer but it would seem to me that there is some rather foolish behaviour going on here.

From the Mozilla Firefox guide:

"Do this automatically for files like this from now on: When this is selected, Firefox will automatically perform the selected action the next time you download a file of this type."

I am a Firefox user. I want my torrent files to always open with uTorrent. It's very simple, I expect when I tell Firefox to ALWAYS open the torrent files with uTorrent that it will ALWAYS do this. This has nothing to do with conforming to web standards but rather conforming to what your USERS tell the web browser to do for them. If a user CHOOSES to break a web standard that's his prerogative as long as Firefox conforms out of the box there is NO PROBLEM to either.

I have been waiting years for this problem to be fixed and have been using torrent watch folders instead as a workaround (because Firefox WILL remember to save files). Google Chrome however works fine and so I have now switched my primary browsing to this browser.

At the end of the day what WE WANT is most important not some open-to-interpretation and user-overridable web standard.

Thanks,

Alex

Comment 29

[Lester Clayton]

I've been doing a fair amount of investigation into this particular issue and I've discovered that the reason why Firefox is prompting you is because there is a header in the servers reply giving it a different filename than the URL requested.  Here is a sample header

Content-Disposition: attachment; filename="A.and.B.Episode.23.PDTV.XviD-FTP.torrent"

If you completely exclude this header, the file loads into uTorrent without prompting at all, except that the filename would be different - for example the filename would be torrents.php.torrent assuming torrents.php was used to download the .torrent file.

I surmise that this is a security feature because the filename is different than the requested URL.  Whilst my example is related to .torrent files, this would be the case for any kind of attachment.

Comment 30

[Dan Mosedale (:dmosedale, :dmose)]

It's not the filename piece per se, it's simply the use of "Content-Disposition: attachment", which is an explicit instruction from the server to prompt.

Comment 31

[Bart Szyszka]

(In reply to comment #30)
> It's not the filename piece per se, it's simply the use of
> "Content-Disposition: attachment", which is an explicit instruction from the
> server to prompt.

But the "Automatically do this..." checkbox is explicitly telling the user that by checking this checkbox, they're agreeing to ignore such prompts (on the client side). What we're talking about here is user experience design. The interface is communicating something incorrectly to the user, making the interface confusing. It's just strange that I have a checkbox telling me I can ignore future prompts that never works in these situations, even in the new Firefox 3.5. I understand the technical reason, but it doesn't make sense the way it's presented to me (I should just not see that checkbox at all for Content-Disposition:attachment if the Firefox developers are going to refuse to honor its setting).

Also, I'm not 100% sure how Firefox works in this, but in Safari on Mac you can Option+click on a link to have its destination downloaded without prompting no matter what. Maybe a good compromise here would be to have a similar force click perform the automatic action without prompting? Obviously this would help advanced users (like people who download .torrent files that just want them to open in their frackin torrent client  ;-)  ), and the issue of that non-working "Automatically..." would still need to be resolved.

Maybe for Content-Disposition:attachment, Firefox needs a list of trusted sites. "[check?] Automatically download files like this at XYZtorrents.com | view trusted sites >>"

Comment 32

[Messrs Germ & Steel]

People this issue has been open since 2004!  Five years have gone by.  Whatever the underlying [very complex] reasons users want to just save the file!

After the 100th click to save a downloading rar file I will now be turning to Safari.  Haven't given up on FF though -- I will keep updating and seeing if this is fixed in version 4.0 or 4.5 or 5.0.

Comment 34

[Felipe]

I am approaching this from a different angle.

We use FogBugz in our dev group to track cases. FogBugz always sends attachments, be they PDFs or what not, with “Content-Disposition” headers.

I want to tell the browser to ignore Content-Disposition headers for this case.

Also, FogBugz sends diffs as application/octet-stream. This may be FogBugz’s problem (and it is, IMO).

At the end of the day, the user should have control over the browser. If the web server wants me to download the PDF rather than display it in the browser, I should be able to refuse that. Even a random octet-stream: if I want to display it in a new tab, warts and all, I should be able to do it, regardless of what the web server “tells” the client to do.

Comment 35

[James May [:fowl2]]

Hopefully unique origin though.

Comment 36

[S A]

"But the "Automatically do this..." checkbox is explicitly telling the user that by checking this checkbox, they're agreeing to ignore such prompts (on the client side). What we're talking about here is user experience design. The interface is communicating something incorrectly to the user, making the interface confusing. It's just strange that I have a checkbox telling me I can ignore future prompts that never works in these situations, even in the new Firefox 3.5. I understand the technical reason, but it doesn't make sense the way it's presented to me (I should just not see that checkbox at all for Content-Disposition:attachment if the Firefox developers are going to refuse to honor its setting)."

Just want to emphasize this comment.

This has been driving me crazy for years now and is still going in in FF 8.  What on earth is the point of the checkbox if it does nothing at all but give the message "go change this setting somewhere else if you actually mean it" (which is basically what it translates to)?  I teach online and have to download literally hundreds of .doc, .docx, and .pdf files every single quarter.

Comment 37

[Mardeg]

(In reply to S A from comment #36)
> I teach online and have to
> download literally hundreds of .doc, .docx, and .pdf files every single
> quarter.
Regarding just this while we wait for a bug resolution I solved it with:
https://addons.mozilla.org/en-US/firefox/addon/inlinedisposition/

Comment 38

[Tim]

@Mardeg, thank you for doing what the FF developers are clearly unwilling do to: providing a mechanism for users to get the functionality that they want, even when that incurs an increased risk (highlighted by RFC 2183), by explicitly accepting that risk (by the action of installing a plugin, since the action of checking the checkbox is ignored by FF).

The comments from FF developers (Gavin, Boris, and others in the various other posts about this issue here in BugZilla) show what they're concerned about (compliance with the suggestions of the RFC, as well as helping to protect users from malicious web sites), and they're right to be concerned about those thing, and to make Firefox's default behavior be the one that is compliant with the RFC's suggestions (the word in the RFC is "should", not "must", as another commenter pointed out).

However, that doesn't mean that Firefox shouldn't allow some other mechanism by which a user could specify that "I know and understand why what I'm asking Firefox to do could leave me more vulnerable to certain risks, but I accept those risks because to me they are better than the pain of the alternatives."  Make the user check a secondary checkbox saying that they understand why defaulting to either Save or Open is a risk.  Make them read a detailed explanation of what the problem is.  Make them take a quiz to prove they really understand that explanation.  Enforce a waiting period like some states do to buy a gun.  Tell them that the web site author probably meant for them to get the choice of whether to Open or Save, and they should re-consider.  Do whatever it takes to relieve your conscience about how you think that implementing this feature is shirking your responsibility as a developer to prevent users from shooting themselves in the foot with this piece of software.  Do whatever you need, but just implement the feature already, so the community as a whole stops wondering what idiot wrote the buggy code that pops up the dialog box with the "do this automatically from now on" checkbox ALREADY CHECKED, yet clearly couldn't figure out how how to look at its state beforehand to determine whether to show the dialog in the first place.  Because that's what most users I've talked to assume from the current behavior, and it sure doesn't do you guys justice for the good work you've done on this browser.

Comment 40

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 41

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 42

[Sylvestre Ledru [:Sylvestre]]

No assignee, updating the status.

Comment 43

[Asif Youssuff]

Users are noticing this issue in 2019: https://www.reddit.com/r/firefox/comments/bxqzlk/is_there_a_way_to_disable_download_prompts_on

It feels obvious that this should be fixed, since Firefox knows that it can't (or won't) respect the checkbox, but exposes it anyway.

Comment 44

[Asif Youssuff]

(In reply to Asif Youssuff from comment #43)

Users are noticing this issue in 2019: https://www.reddit.com/r/firefox/comments/bxqzlk/is_there_a_way_to_disable_download_prompts_on

It feels obvious that this should be fixed, since Firefox knows that it can't (or won't) respect the checkbox, but exposes it anyway.

...and again in 2020 - https://www.reddit.com/r/firefox/comments/g9nvl7/i_love_you_firefox_but_oh_my_god_will_this_button/

Comment 45

[andreas.fischlin]

Yes it would be time to address this as it 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.

Comment 46

[Mathew Hodson]

Is this still relevant? I see Mozilla has a Jira issue associated with this bug.

Comment 47

[:Gijs (he/him)]

I don't think there's anything left to do here, no.