Closed Bug 236541 Opened 21 years ago Closed 19 years ago

"do this automatically for files like this" doesn't work when Content-Disposition:attachment is used

Categories

(Core Graveyard :: File Handling, defect, P2)

Product:
Core Graveyard
Component:
File Handling
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: jdarpinian, Assigned: bzbarsky)

References

Details

(Keywords: fixed1.8.1)

Attachments

(4 files)

picture of open dialog
13.38 KB, image/png
Details
default filetype actions
57.23 KB, image/png
Details
JPEG Image File Association
45.46 KB, image/jpeg
Details
Patch for the core code per comment 38.
4.11 KB, patch
Biesinger
: review+
darin.moz
: superreview+
benjamin
: approval-branch-1.8.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040304 Firefox/0.8.0+ (BlueFyre)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040304 Firefox/0.8.0+ (BlueFyre)

I haven't yet figured out what causes this bug on some files and not others, but
sometimes the "do this automatically for files like this" checkbox doesn't work.
 It happens for me repeatably at:

http://media.ebaumsworld.com/index.php?e=homebase.asf

No matter how many times I download the file and check the box, Firefox still
asks me what to do with it.

Reproducible: Always
Steps to Reproduce:
I can't reproduce this. It seems to work fine for me whether I choose to always
save, or always open. I'm using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040302

Can you try to reproduce this using the latest OFFICIAL build, available from here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Also, please remember that when you install a new build, you need to delete the
old install first so you install in an empty folder. Also, please test using a
clean profile. To do this, delete or move away %AppData%\Phoenix.

Let us know how this works out for you.
Correction: The UA I tested with in comment 1 is actually the following:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040302
Firefox/0.8.0+
Still happens for me at the given URL with latest official installer build and
brand spanking new profile.  Perhaps it has something to do with my file
associations for .asf files?
Perhaps, are you using Windows Media Player 9 to view your ASF files by default?

Also, can you try it with the latest non-installer build?

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-03-02-08-trunk/Firefox-win32.zip

Just extract this into an empty directory.
Attached image picture of open dialog — 

    
    

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

    
    

    
  
One more thing to try. When you choose do this automatically for all files like
this, pull down the drop down menu next to open with, and browse to the
winamp.exe file, and see if it remembers that. Also, go to Tools | Options |
Downloads and see if the appropriate entry is there.

I forgot to ask earlier, are you seeing this behaviour only on this file type,
only on this URL, or on many file types or URLs. Even before, was there an entry
made in Tools | Options | Downloads relating to how to download ASF files?

Also, if anyone else is out there reading this, can you reproduce this?

    
    

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


    
    

    
  


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

If I delete all of these filetype actions, then everything seems to operate as
it should, with the "do this automatically for files like this" checkbox
working as intended in every case (even ASF).

    
    

    
  
Confirming bug on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040302
Firefox/0.8.0+

It appears that in this case, the ASX/ASF entry is a shared one (and that there
is a problem with it). If you delete the default one that Firefox creates
(leaving all the others there), it works okay.

This may just be a more general problem of that affects things where you don't
use the default file handler.

--> NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

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

    
    

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

    
    

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

Updating summary.
Summary: "do this automatically for files like this" checkbox doesn't always work → "do this automatically for files like this" doesn't always work with php scripts

    
    

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

    
    

    
  
Further (and not directly related to this report) the page being created by the 
PHP server intends for the graphic to be displayed on the page, not handled by 
download manager.  A blank window/tab is opened; download manager started, and 
the blank window/tab must be closed by hand.  This may not be relevant...

Should an examination of the stream being provided by the PHP server be needed, 
I can do a line trace to capture it.

    
    

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

    
    

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

    
    

    
  
Once again, I'll say that this problem is caused (at least in some cases) by the
default actions Firefox creates when installed.  There are several reasons why
these actions are bad:

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

    
    

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

    
    

    
  
I'm able to duplicate this bug. Visit http://www.emusic.com (you don't have to
be a member), and try to preview songs. It'll prompt you with the "You have
chosen to open" dialog every time you click one of the m3u links.

As requested in one of the posts here, I've verified that M3U is in
tools->options->downloads. It's set up to automatically open files with M3U
extensions with the default application "m3ufile".

There is no indication that the server is running PHP, and it's not being
accessed via HTTPS.

"Trying 64.124.6.60...
Connected to www.emusic.com.
Escape character is '^]'.
HEAD /m3u/song/10844133/13120918.m3u HTTP/1.0
Host: www.emusic.com

HTTP/1.1 200 OK
Date: Mon, 10 Jan 2005 02:50:46 GMT
Server: Apache/1.3.29 Ben-SSL/1.53 (Unix) mod_jk/1.2.0
Expires: Mon Jan 10 21:50:48 EST 2005
Cache-Control:
Content-Disposition: 13120918.m3u
Content-Length: 0
Connection: close
Content-Type: audio/x-mpegurl"

I'm running:

"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0"

    
    

    
  
I see this exact thing when downloading my financial statement into Quicken. On
one of my banks sites(https://www.atbfinancialonline.com/) the file automaticlly
launches and opens quicken, on the
other(https://www.cibconline.cibc.com/bvtrx01/script-root-tran/accounts/TransactionDownload2.cibc)
the dialog to open the file or save it comes up everytime. The option to "do
this automaticlly" is checked already when the dialog box comes up. 

This should demonstrate that the setting is correctly set in firefox its
something about how firefox gets the file from the two different sites. If
someone would like some actually raw http headers or something i would be happy
to grab that info, but i'm not sure what you would want. Let me know.


    
    

    
  
I believe this bug has to do with servers that send Content-Disposition headers.
 I see this problem with bittorrent sites.  On some, the torrent is
automatically downloaded and launched in Azuereus, my configured handler for
torrent files.  On other sites, I get the "What do you want to do with this
file" dialog box.  I wrote a simple script which helped me reproduce it:

<?PHP
$filename = "test.torrent";
$fn = $filename;
header("Content-Length: " . filesize($fn));
header("Content-Transfer-Encoding: binary");
//header("Content-Disposition: attachment; filename=\"" . $filename . "\";");
header("Content-Type: application/x-bittorrent");
header("Transfer-Encoding: chunked");

@readfile($fn);
?>

If I uncomment the Content-Disposition header, I receive the dialog prompt. 
Otherwise, as is, the file gets downloaded automatically.  Does anyone know if
there's something in the RFC about Content-Disposition which mandates that the
user should be prompted?  If this is indeed the distinguishing characteristic
that causes the dialog prompt, is it really a bug?  I'd personally like for the
"Always do this" option to do what it says.

    
    

    
  
According to the Content-Disposition RFC http://www.faqs.org/rfcs/rfc2183.html

2.2  The Attachment Disposition Type

   Bodyparts can be designated `attachment' to indicate that they are
   separate from the main body of the mail message, and that their
   display should not be automatic, but contingent upon some further
   action of the user.  The MUA might instead present the user of a
   bitmap terminal with an iconic representation of the attachments, or,
   on character terminals, with a list of attachments from which the
   user could select for viewing or storage.

This makes it sound like Firefox is doing the technically correct thing.  So,
I'd like to suggest a setting that would allow users to indicate that
attachments should also be handled automatically.  Or would this be better as an
extension?

    
    

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

    
    

    
  
OK, I give up.  I've spent over two hours investigating this, trying different
combinations of mimetypes, content-distribution headers, and file extensions.  

I have figured out that if content-distribution:attachment is used, the dialog
always shows up.  I think it shouldn't if you've set auto-downloading.  So this
bug is valid the way it is and should be easily fixable.

However, in all other cases (when the mimetype is application/octet-stream,
text/plain, or an unknown mimetype), Firefox's behavior is totally inconsistent,
even when it guesses the filetype correctly.  Sometimes the auto-download
checkbox is disabled (though sometimes a previously set auto-download preference
will still work on these files, and sometimes not), sometimes the checkbox is
enabled but it doesn't work (though I've run into this in the wild I can't
reproduce it now), sometimes the same file served with a different mimetype will
have separate auto-download settings (so the same file extension is listed twice
in the options dialog), but sometimes not.  

Which problems happen seems to depend on how your file associations are set up
in Windows, and also which filetypes you have set to auto-download already,
through some complex mechanism I haven't figured out.  I think further
investigation can only be done by someone looking at the actual code.

    
    

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

    
    

    
  


  

    
    

    
  
The "Do this automatically for files like this from now on." implies that the
dialog box should not appear. I have this same problem when clicking on
attachments in Yahoo webmail where the 'sending' email client does not properly
inline the attachment as image/jpeg. 

Email tests to my yahoo account with an attached JPEG, from AOL webmail, Eudora,
Gmail, Hotmail, and Outlook XP all produce the dialog box before opening. I have
the settings set to open JPEGs in Firefox.

Email tests to a yahoo account with an attached JPEG from Yahoo Webmail or from
the [great] Thunderbird do properly inline the attachment as image/jpeg and when
clicking on the attachment in yahoo webmail, the image opens in a new Firefox
window. (no dialog box)




    
    

    
  
I do not think this is a bug.

FireFox is doing exactly what the RFC for "Content-Disposition" says to do when 
the disposition type is "attachment".

See the RFC:
http://www.faqs.org/rfcs/rfc2183.html


From the RFC for disposition types of "attachment" it says:

2.2  The Attachment Disposition Type
 
   Bodyparts can be designated `attachment' to indicate that they are
   separate from the main body of the mail message, and that their
   display should not be automatic, but contingent upon some further
   action of the user.  The MUA might instead present the user of a
   bitmap terminal with an iconic representation of the attachments, or,
   on character terminals, with a list of attachments from which the
   user could select for viewing or storage.
 
 
Note, that line that says: "display should not be automatic, but contingent 
upon some further action of the user."

I believe that FF should give the user some indication of why it is not 
following the user's requested action.



For developers:
I developed an application that was using the "Content-
Disposition:attachment;filename=..." and I was having problems.  I switched 
my "Contenet-Disposition" header to replace the word "attachment" to "inline" 
and this solved my problems.

Here is what the RFC says about the disposition type "inline":

2.1  The Inline Disposition Type
 
   A bodypart should be marked `inline' if it is intended to be
   displayed automatically upon display of the message.  Inline
   bodyparts should be presented in the order in which they occur,
   subject to the normal semantics of multipart messages.
 

 

So I think the problem is that FF is doing what the RFC says to do, but it is 
not telling the user why it is not following the users specified instructions.

    
  
Assignee: bugs → nobody
QA Contact: aebrahim-bmo → download.manager

    
    

    
  
As an end user, this would just further my frustration: a computer program
telling me "I'm ignoring your preferences in favor of some random webmaster's
preferences" -- Might as well be using Internet Explorer. :-)

A compromise might be to have an option that the user can set, that would allow
the browser to ignore RFC2183 2.2.

    
    

    
  
(In reply to comment #29)
> I do not think this is a bug.
> [...]
> See the RFC

I disagree very strongly.  I have already explained why this exact section of
this RFC does not prohibit Firefox's automatic downloads.  Let me repeat myself:

The RFC states that *display* of the attachments should not be automatic, but
that the program should present the user with a *list of icons* representing the
attachments.  The download manager fits that description perfectly, as it does
not display the files but merely icons.  To display the files, the user must
take the "further action" of double-clicking, exactly as described in the RFC. 
The RFC says nothing about whether or not the file should be downloaded, but
this is probably because it is talking about *mail clients*.  Since Firefox
isn't a mailer, the exact wording of the RFC can hardly apply.  The fact that
Firefox automatically begins downloading the files could simply be seen as a
highly effective pre-emptive caching strategy :-)
Assignee: nobody → bugs
Flags: blocking-aviary1.1+

    
    

    
  
I am observing this on Debian bug reports, e.g. the log files attached to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320627&msg=32

RFCs are all well and good, but being forced to use an external program to view
a text file really is rather silly.

    
    

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

    
    

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

So a sufficiently empowered user needs to remove the blocking1.5+ flag and
change the blocking1.8b4 to +
Flags: blocking-aviary1.5+ → blocking1.8b4?

    
  
Flags: blocking1.8b4? → blocking1.8b4-

    
    

    
  
This bug, as summarized, is invalid, per comment 29 and others. The fix in this
case is to grey out the checkbox when Content-Disposition: attachment is used,
and that's bug 285976.
Assignee: bugs → nobody
Depends on: 285976
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk

    
    

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

Enough people have pointed out that firefox's behavior is correct according to
the RFC, but enough people have also pointed out that its very irritating. 
Invalidating this bug and/or making the "Remember this" checkbox readonly will
not, in my opinion, do anything to *enhance* the user's experience but will keep
things frustrating.  What are we users who hate this behavior supposed to do? 
Petition to change the RFC?  If we're not going to "fix" this bug, is there
anyway for those of us who what the behavior changed to get our wish?  Would an
extension solve this?

    
    

    
  
(In reply to comment #35)
> This bug, as summarized, is invalid, per comment 29 and others

This bug is valid, as I have explained twice already in comment 31 and comment
24, directly addressing the issues brought up in comment 29 and others.  Do you
disagree with my argument?

    
    

    
  
So there are two issues here.

1)  UI bug.  If the "do this automatically" checkbox setting for a file will
just be ignored, then it should be disabled or not even present.  Seamonkey gets
this right, for example.  This seems to be covered by bug 285976.

2)  Correct general behavior.  The key is that for
content-disposition:attachment silent handling of data by the browser, a plugin,
or a helper application is not acceptable.  The former two cases are handled by
not even trying to handle that way.  The last case is handled by forcing the
helper app dialog to come up even if the "don't show the dialog" preference is set.

Perhaps what we should do instead for #2 is to force the dialog up if any action
other than "save as" is selected.  If the user has chosen to save some sort of
data, then it should be fine to just silently do that for
content-disposition:attachment.  Combined with fixing bug 285976, that should
address the issues this bug was filed on, I think.

biesi, thoughts?  I believe this would take nsExternalHelperAppService changes,
so perhaps we should move this bug to core.
Component: Download Manager → File Handling
QA Contact: download.manager → file.handling

    
    

    
  
(In reply to comment #38)

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

    
    

    
  
> 4. The change has zero disadvantages; compatibility with all websites is
> unaffected,

Actually, this is the point.  Compatibility _is_ affected.  Consider a
multipart/x-mixed-replace document with a part that is
content-disposition:attachment and isn't the last part (this is UI that appears
in several government document management systems; the attachment part is
typically the document in question as a PDF, while the other parts are some sort
of "waiting" and "document generation done" text).  If we handle the attachment
inline in this case the user will simply never see it, since the following part
will immediately replace it.  There are also some other cases where the intent
of the website is to allow the user to save something and showing the data in a
helper app would actually make that impossible (some viewers have no "save as"
functionality, since they don't support editing).

All of this is easy to figure out by looking at the bugs that caused the current
code to be written the way it is, so I have to wonder where this "compatibility
with all websites is unaffected" idea came from.

    
    

    
  
(In reply to comment #40)

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

    
    

    
  
> Furthermore, it will *always* appear in the download manager

We're talking about a core change, so the details of the Firefox UI are
irrelevant here.  There are apps other than Firefox using this code.

    
    

    
  
(In reply to comment #42)
> the details of the Firefox UI are irrelevant here.

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

    
    

    
  
> Are you saying it's impossible to change this in Firefox's UI without a core
> change

Yes.  See comment 38.

> Surely there is a way to fix this in a less invasive manner.

Not as things stand.  The decision on whether to pose the dialog is made in core
code, and the actual execution of the chosen action is performed there as well.
 The app merely provides the implementation of the dialog.

    
    

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

    
    

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

    
    

    
  
If so, perhaps the contract should be changed.  Alternatively, wouldn't it be
possible to change the core in such a way that the new behavior happens only
when an option is set, preventing other applications from being affected? (as I
was trying unsucessfully to get at in the part of my question omitted from your
reply)

In any case, if still you believe enabling automatic helper apps for attachments
is wrong or infeasible, I will be happy if only automatic downloads are enabled
for attachements, as you originally proposed.  I don't often use automatic
helper applications anyway.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
(In reply to comment #52)
> *** Bug 309013 has been marked as a duplicate of this bug. ***

well im dumb, and made a dupe bug. My two cents is that when a checkbox that is
equivalent to "dont show me this again" is checked, it should never show up
again with out going through some config screen or file.



    
    

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

    
    

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

    
  
Flags: blocking1.8rc1?
Flags: blocking1.8rc1?

    
    

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

    
    

    
  
(In reply to comment #56)
> Re-installing Mozilla will "sometimes" correct this bug

If that's true, you're not seeing this bug.

    
    

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

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



    
    

    
  
(In reply to comment #58)
> I tried that, and behold it corrected the problem on my
> computer at home (Word and PDF files now open automatically) but the same "fix"
> had no effect at all on the computer I use at work.  I am not making this up.

I'm not accusing you of making it up, I'm simply pointing out that your issue is
a different bug, not this one. This bug is about Firefox ignoring "do this
automatically" for files sent with content-disposition: attachment, as stated in
the summary.

    
    

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

    
    

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

    
    

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

    
    

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

    
    

    
  
I have a PHP script that creates a plain .txt file and sends these headers:
Content-Type: application/force-download
Content-Type: application/octet-stream
Content-Type: application/download
Content-disposition: attachment; filename=file.txt

And the Open dialog still shows up even after I click "Do this automatically...". I'm using Firefox 1.5 RC 1 on OS X.

    
    

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

/be

    
    

    
  
the component is right, the product probably is as well, firefox should just disable the checkbox in this dialog, like seamonkey does (in the cases where it doesn't work).

although if comment 38's issue 2 is to be solved in the proposed way, then this does belong into core...

    
    

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

    
    

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

Agreed.

Biesi, if you agree, can you reassign and otherwise fix up this bug's fields?  I bet bz will have something to say when he's back after the holidays, but it would be good to get this bug moved to Core right now.  Thanks,

/be
Assignee: nobody → file-handling
Product: Firefox → Core
QA Contact: file.handling → ian

    
    

    
  
Hello.  I was referred to this bug by someone who believes that this bug describes what I am experiencing.  So hopefully this will help.

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

    
    

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

    
    

    
  
(In reply to comment #70)
> This BUG show just how out of touch with reality Firefox's developers are. Who
> gives a rat's ass about whether the program is following some protocol properly
> or not. To the end user it is not doing what it has been told to do and is
> therefore a bug.

Thanks for the bile.  I agree that this is a Firefox bug to be fixed as soon as possible.  That's why I stirred the pot, and why this bug will be fixed in the next release.

But your comment is worse than useless in getting this bug fixsd.  It's not as if "Firefox's developers" actually said this bug shouldn't be fixed.  Clue: Mozilla is an open source project, and our bug database gets comments from any loudmouth who wants to give an email to get a login.  Don't assume all such people are "Firefox's developers".

Keep it productive, if not civil.

/be

    
    

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

    
    

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

See bug 315536.

/be

    
    

    
  


  

        Attachment #208411 -
        Flags: superreview?(darin)

        Attachment #208411 -
        Flags: review?(cbiesinger)

    
    

    
  
Comment on attachment 208411 [details] [diff] [review]
Patch for the core code per comment 38.

+  mMimeInfo->GetPreferredAction( &action );

probably more in line with the style of this file to remove the additional spaces (though the file is inconsistent...)

        Attachment #208411 -
        Flags: review?(cbiesinger) → review+

    
    

    
  
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Firefox 1.5 on Mac OS X 10.4.4

+Confirm that 'Do this automatically is ignored.

Also,  if I attempt to edit the actions entry in:
Preferences | Downloads | View & Edit Actions
I cannot choose an application.  The exact behavior is this:

1. Goto View & Edit Actions
2. Click on Change Action... (in my case for VCF, which is a vCard file)
3. Pick 'Open them with this application:'
4. Browse... to and select Address Book.app
5. [Address Book is not filled in, seems to be ignored]
6. Click OK
7. [My entry for VCF shows the action as 'Open with', but nothing more]

Interestingly, in step 4, the icon for Address Book is shown, but nothing is filled in as the  name of the application.

    
    

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

    
    

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


    
  

        Attachment #208411 -
        Flags: superreview?(darin) → superreview+

    
  
Assignee: file-handling → bzbarsky
Priority: -- → P2
Target Milestone: --- → mozilla1.9alpha

    
    

    
  
Fixed on trunk.  The core issue, that is.  Please take remaining Firefox UI issues to Firefox bugs. 
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
    

    
  
Comment on attachment 208411 [details] [diff] [review]
Patch for the core code per comment 38.

I think we want this behavior change on the 1.8.x branch....  Risk is that an existing embeddor that depends on current behavior will suddenly not get promps coming up in some cases.  But this is a Gecko policy decision, really, so I think this is ok.

        Attachment #208411 -
        Flags: approval1.8.1?

    
  
Flags: blocking1.8.1?

    
    

    
  
Comment on attachment 208411 [details] [diff] [review]
Patch for the core code per comment 38.

bz is module owner and requested approval, so I'm going to mark branch-1.8.1+ for him

        Attachment #208411 -
        Flags: approval1.8.1? → branch-1.8.1+

    
    

    
  
Fixed on branch.
Keywords: fixed1.8.1

    
    

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

    
    

    
  
Many membership torrent sites (torrentbits clones) use attachement in their download.php scripts. If needed I can provide URLs (in private) that shows this bug.

If this is 'fixed' as per comment #38 the correct resolution imho would be WONTFIX _or_ bug 325551 should be reopened, since that one is for firefox specifically. 

The whole point is that since core seems to throw up the dialog before any extension/plugin/dowloadmanager even has a chance to kick in it CAN NOT be made to work if the user wants to open something even after this 'fix'.
This actually boils down to a removal of functionality. Please re-read comment #30.


    
    

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

    
    

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

    
    

    
  
Well, let me also one more "confirming the bug." 

I my case Firefox ignores default action for *.jpg
files, as does with many, many others. The box 
"Do this automatically for files like this from now on"
is checked, and I still get the confirmation dialog. 

My default application for *.jpegs is the well known
Irfanview. The file name is all in capital, if it might
be of interest. 

Worrisome in this case is the very long list of 
"I cannot reproduce" kind of replies and consequently, 
no fix is provided for the nuisance. 

With the complex profile data filing of Firefox I even
do not any idea where is my current user profile! For
example, I can see the size of my cache, but the
setup applet does nto volunteer the directory of
the cache!

Otherwise I would have tried to quote here my settings 
for automated file actions. 

You also indicate this as "resolved fixed." What is fixed, 
if I may ask?


    
    

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

    
  
Flags: blocking1.8.1?

    
    

    
  
How about just fixing the download actions bug (and other bugs) before release?

Frankly I find it pretty incredible that you release something without going through the Options menu and checking that it all works. In fact I find it so incredible that I don't believe it, I'm left believing that Mozilla couldn't really care less about the experience of users. 

One journalist who'll be giving you a negative write-up.

    
    

    
  
30 April 2006

How about just fixing the download actions bug (and other bugs) before release?

Frankly I find it pretty incredible that you release something without going through the Options menu and checking that it all works. In fact I find it so incredible that I don't believe it, I'm left believing that Mozilla couldn't really care less about the experience of users. 

One journalist who'll be giving you a negative write-up.

    
    

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



    
    

    
  
I'm trying to get this work properly, the work web server (unfortantly I dont have access to the source) is using a php script to create the pdf and then launched via fpassthru() and everytime I open it ask if I want to open it via acrobat everytime regardless from the "do this automatically from now on", or the always open in "acrobat" option

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060721 Firefox/2.0b1

    
    

    
  
(ok, lets try that again..)

I'm trying to get this work properly in the latest branch builds, the work web server (unfortantly I don't have access to the php source or the server). 

A php script generates pdf and then launched via fpassthru()
It opens a perfectly valid FF "Open Dialog" and suggests acrobat

regardless of the "do this automatically from now on" is selected, it will still open the "Open Dialog" Window, could anyone make a testcase that could defeat this patch? (if I explained it properly)

format of the url, http://somedomain.com/sendpdf.php?type=receipt&transact_id=115831

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060721
Firefox/2.0b1

    
    

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

    
    

    
  
See also bug 354400

    
    

    
  
Just to add to other experiences recounted here ... [see comment #69]

I've used every version of FF and the failure of the download manager to remember "do this automatically..." settings has happened with each and every version from 1.5 onwards. I check each new release and, so far, have consistently had to revert to 1.0.8 to avoid this extremely annoying bug.

1.0.8 has never, repeat, never failed to honour a "do this automatically ..." setting for any filetype.

So the obvious question is what is different about the download manager in subsequent versions which leads to the same files (never mind filetypes) being treated differently?

    
    

    
  
Bug 331259 is essentially a duplicate of this syndrome posted for Firefox. The current disposition indicates that a fix will be implemented in FF3 M11. It also indicates that it is in the Download Manager.

Does this imply that it will be reflected in a future SM release as well or is there a different Download Manager for SM builds ?

    
    

    
  
WRT to RFC compliance, there is a parallel discussion in Bug 331259 starting with Comment #25:
 
>[...]
> Of course Firefox could ignore the Content-disposition header but then it 
> would not be standards-compliant.

The operative word in the RFC 2183 extract is "should not". According to RFC
2119 #4:

"SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."

Thus, the suggested change (always allow the user the option of automatic action regardless of content disposition type) can be implemented without
violating RFC 2183.

    
    

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

    
    

    
  
Another point of consideration when implementing these changes -

Bank of America's on-line banking downloads for Quicken or MS Money are coded with content-disposition:attachment. With the current FF/SM implementations, this forces the user to answer the dialog on every download, even though the only practical use of the file is to be opened by the targeted finance application.

A discussion with BOA's technical support indicated that the rationale for this (vs. :inline) is a function of the way IE handles downloads. If the download invokes an application directly, IE will NOT save the file on the user's system. This unlike SM/FF behavior which always saves the file. They are unwilling to change this at this point as their IE users are accustomed to the file download.

    
    

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

    
    

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


    
    

    
  
The suggested change in _this_ bug was that selecting "always handle in helper app" for a type on one site, without any content-disposition involved, would thereafter apply to all sites and all content-disposition values.

If there is now another proposal (presumably in another bug), that's great.  But that discussion belongs in said other bug.

    
    

    
  
(In reply to comment #102)
My experience is on SM/FF on OS X. In the instance of automatic d/l handling, the target app is opened with the downloaded data as well as the data being saved in a file in the user's selected download destination.

This behavior can be exhibited with similar downloads from CitiBanks online banking site which encodes their downloads as inline.


    
    

    
  
OK. I didn't catch that subtlety in the description.

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


    
    

    
  
> My experience is on SM/FF on OS X.

Ah, yes.  The OS X mess.  Historically Mac users expect all downloads to be dumped to their Desktop, apparently.  So we never delete temp files on Mac, unlike other OSes.  Of course non-fanatical Mac users actually want the files deleted, etc, etc.

I can see making this behavior different on OSX only if the preference to delete temp files is not set.  Please file a separate bug on that.

Bug 331259 seems to be about a slightly different problem and is being hijacked with content-disposition discussion, as far as I can tell.

And yes, the code changed in this bug applies to all Gecko apps.  However the front end can avoid prompting if it wants to: we tell it exactly why we're asking it to prompt.

    
    

    
  
Looks like Bug 331259 started as an issue with FF where the d/l manager would remember the "do this automatically..." and "open with" settings (radio button and helper app), yet still prompt the user for action. It then morphed into a  different discussion from regarding standards compliance and over content disposition handling.

In the case of SM, the d/l behavior is slightly different. The dialog will still appear, but the "always perform this action..." option is grayed out, the target application is remembered, yet the "save it to disk" option is always checked.

If it would help, I can supply screen snapshots for both FF and SM (OS X build) with a download disposition of attachment.

    
    

    
  
Yes, the morphing should never have happened.

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

    
    

    
  
What I was looking for was to have the user option of invoking automatic helper action for disposition:attachment be the same as for in-line assuming there is a match to a defined MIME type definition. Essentially, honor the MIME handling options present in Preferences/Navigator/Helper Applications and make them stick.

It appears that there have been a number of bugs started at one time or another on this behavior. Bug 331259 was opened for FF / Download Manager.  Coupled with its' "morphing" from the original request, should a new bug be started with SM or core as a baseline ?

 

    
    

    
  
I think the core behavior here is largely correct: notify the UI that there is a load with a certain type and content-disposition:attachment.  What the UI does with that is up to the UI...

Also, as I said, I could see an argument for changing the core behavior in the case when we're going to save the file anyway (Mac only, basically).  That should go into a separate bug from any UI issues.

    
    

    
  
I just want to clarify, at this point the core is properly notifying the UI about the content-disposition, and the UI is capable of handling the attachment any way it sees fit (including silently), and it is the UI and UI alone that is making the decision?

bz's last comment 111 about possibly "changing the core behavior in the
case when we're going to save the file anyway" seems to contradict the idea that the core is already handing the UI all the power to handle things as this bug requested.

At this point bugs about the issue are being marked as duplicates of *this* bug or bug 331259, both of which are marked as fixed. The actual functionality that users are intending when filing all these bugs is not being achieved, and we need to know which component *that* bug needs to be filed for, or which bug needs to be reopened or whatever.

    
    

    
  
More (especially wrt Firefox behavior) in bug 453455.

    
    

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

Thanks for listening.

    
    

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

Thanks!

    
    

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

    
    

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

    
    

    
  
I have here the same problem with Windows 7 and Thunderbird 38.2.0. It is not possible to use the inlinedisposition addon because it is not compatible with this version.

On my other workstation with Ubuntu 15.04 and Thunderbird 38.2.0 I can open the attachment and set "do this automatically ..."

    
    

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

    
    

    
  
I confirm that  "do this automatically for files like this" doesn't work when Content-Disposition:attachment is used.

This means that this bug is not fixed and should be reopened or labeled as WONTFIX (see https://bugzilla.mozilla.org/show_bug.cgi?id=236541#c84 and https://bugzilla.mozilla.org/show_bug.cgi?id=236541#c114).

(I also confirm that addon InlineDisposition is a workaround)

    
    

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

    
    

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

    
    

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



    
  
Blocks: 285976
No longer depends on: 285976

    
  
Blocks: 331259

    
  
Blocks: 453455

    
  
URL: http://media.ebaumsworld.com/index.ph...
Flags: needinfo?(jdarpinian)

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: