We've just modified Bugzilla to use Content-Disposition to suggest the correct filename for attachments. However, this doesn't work in recent Mozillas (> 1.1; 1.1 and 1.0 work fine), because when you go to Edit the attachment, and it's displayed in an iframe, you get a download dialog. Commenting out the Content-Disposition line: print qq{Content-Disposition: attachment; filename=$filename\n} if $usedisposition; fixes the problem. See URL for test case. Build ID: 20020927 Linux Red Hat 7.1. Gerv

-> file handling

setting OS/Platform to all/all Reproduced on MacOS X CFM 2002092511 Noting the conversation in the original bug where we were discussing implementing this feature, Internet Explorer 4.x had this same bug, and Microsoft admitted it was a bug and fixed it in 5.0 (this we have browser-sniffing code in Bugzilla to not send that header if it's Internet Explorer < 5.0) This has always worked in Netscape/Mozilla and just recently got broken. (It worked fine in Mozilla 1.1 release)

Behavior in the current builds: When a "Content-Disposition: attachment" header is present, a file download dialog is always presented. Correct behavior: When a "Content-Disposition: attachment" header is present, a file download dialog is ONLY presented if the file is not a viewable mime type. If the mime type is viewable by Mozilla, it is displayed in the browser window, but the filename information from the Content-Disposition header is held on to and is used if the user chooses "Save As..." after viewing the page.

This change was purposeful. It's IE-parity (certainly for top-level documents, though perhaps not for iframes) and as far as I can tell the closest we can follow the spec on this matter. If you just want to suggest a filename, you want: Content-Disposition: inline; filename="whatever" which is more in keeping with the way you want it treated anyway. I'm very very tempted to just wontfix this, but would like a pointer to the "Microsoft admitted it was a bug" information first. See also bug 98360, which is what we fixed to trigger the current behavior.

http://support.microsoft.com/default.aspx?scid=KB;EN-US;q182315&

Uh, nevermind me for trusting what I'm told compared to reading it. This is a Bugzilla problem. http://support.microsoft.com/default.aspx?scid=KB;EN-US;q221998& is the correctly relevant article. I could swear there was some reason we specifically didn't use 'inline' before, but I can't find it now.

OK, I found the reason we didn't use inline before. IE5 completely ignores the filename if you use inline. So you either force it to download or you forget about supplying a suggested filename. Nice. I suggest we use inline and people who feel compelled to use IE will have to live with the way it's worked for the last two years.

Also removing the IE4 hack, since we had it backwards... the bug in IE4 was that it *didn't* put up a download dialog. In IE5 it does. Except on the Mac version. IE5.2/Mac completely ignores the filename if you use inline. So this is now going to be completely useless on IE5. oh well.

Comment on attachment 100971 [details] [diff] [review] change "attachment" to "inline" This sucks.... r=bbaetz x2, if bz thinks it works :)

Comment on attachment 100971 [details] [diff] [review] change "attachment" to "inline" That implies to me that you want bz to check off the second-review box. :-) This is live at http://landfill.bugzilla.org/bz63601/attachment.cgi?id=4&action=edit if anyone wants to play with it.

Comment on attachment 100971 [details] [diff] [review] change "attachment" to "inline" It had better work in Mozilla... we made it work very purposefully. ;) We don't support internationalized filenames yet (and neither does bugzilla, based on that patch), but other than that, we should be cool. I don't have a good way to test right now, but I've tested that exact header in Mozilla before and if someone has broken it I'll make sure the culprit suffers....

Comment on attachment 100971 [details] [diff] [review] change "attachment" to "inline" It had better work in Mozilla... we made it work very purposefully. ;) We don't support internationalized filenames yet (and neither does bugzilla, based on that patch), but other than that, we should be cool. I don't have a good way to test right now, but I've tested that exact header in Mozilla before and if someone has broken it I'll make sure the culprit suffers....

Comment on attachment 100971 [details] [diff] [review] change "attachment" to "inline" It had better work in Mozilla... we made it work very purposefully. ;) We don't support internationalized filenames yet (and neither does bugzilla, based on that patch), but other than that, we should be cool. I don't have a good way to test right now, but I've tested that exact header in Mozilla before and if someone has broken it I'll make sure the culprit suffers....

Comment on attachment 100971 [details] [diff] [review] change "attachment" to "inline" It had better work in Mozilla... we made it work very purposefully. ;) We don't support internationalized filenames yet (and neither does bugzilla, based on that patch), but other than that, we should be cool. I don't have a good way to test right now, but I've tested that exact header in Mozilla before and if someone has broken it I'll make sure the culprit suffers....

Comment on attachment 100971 [details] [diff] [review] change "attachment" to "inline" It had better work in Mozilla... we made it work very purposefully. ;) We don't support internationalized filenames yet (and neither does bugzilla, based on that patch), but other than that, we should be cool. I don't have a good way to test right now, but I've tested that exact header in Mozilla before and if someone has broken it I'll make sure the culprit suffers....

Comment on attachment 100971 [details] [diff] [review] change "attachment" to "inline" It had better work in Mozilla... we made it work very purposefully. ;) We don't support internationalized filenames yet (and neither does bugzilla, based on that patch), but other than that, we should be cool. I don't have a good way to test right now, but I've tested that exact header in Mozilla before and if someone has broken it I'll make sure the culprit suffers....

Hmm... My apologies for the tons of posts... IE5.5 here just kept showing me the "edit attachment" page after I hit the submit button, but it apparently sent the data to the server. There was no evidence of network activity, so I bonked the button a few more times just to make sure... Now, 3 minutes later, it finally showed the "attachment edited" page. Sigh....

you can change the "edit" on the end of that url to "view" if you want to see the attachment on its own page instead of in the IFRAME.

Checking in attachment.cgi; /cvsroot/mozilla/webtools/bugzilla/attachment.cgi,v <-- attachment.cgi new revision: 1.25; previous revision: 1.24 done

so um... if this is a problem on MSIE, but can be fixed by using attachment rather than inline, why not check the user-agent and send attachment if it detects MSIE?

We probably could. Anyone know what specific versions of MSIE don't honor inline filenames and also don't honor a disposition of 'attachment' to force a download? I only have the Mac version to test, and it doesn't. According to the Microsoft Q articles referenced above, MSIE forces a download on an 'attachment' disposition (which is what we don't want), so obviously the Mac version of MSIE is broken since they claim they fixed that already.

Related: bug #185618