Content-Disposition: attachment brings up Downloading dialog

RESOLVED FIXED in Bugzilla 2.18

Status

()

Bugzilla
Attachments & Requests
--
major
RESOLVED FIXED
16 years ago
6 years ago

People

(Reporter: gerv, Assigned: myk)

Tracking

2.17
Bugzilla 2.18

Details

(URL)

Attachments

(1 attachment)

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

Comment 1

16 years ago
-> file handling
Assignee: darin → law
Component: Networking: HTTP → File Handling
QA Contact: httpqa → sairuh
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)
OS: Linux → All
Hardware: PC → All
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.
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.
Assignee: law → myk
Component: File Handling → Attachments & Requests
Product: Browser → Bugzilla
QA Contact: sairuh → matty
Target Milestone: --- → Bugzilla 2.18
Version: other → 2.17
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.
Created attachment 100971 [details] [diff] [review]
change "attachment" to "inline"

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 :)
Attachment #100971 - Flags: review+
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.
Attachment #100971 - Flags: review+
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....
Attachment #100971 - Flags: review+
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
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
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.

Comment 22

16 years ago
Related: bug #185618
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.