171296 - Content-Disposition: attachment brings up Downloading dialog

Status: RESOLVED FIXED

(Bugzilla :: Attachments & Requests, defect)

Description

[Gervase Markham [:gerv]]

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

[Darin Fisher]

-> file handling

Comment 2

[Dave Miller [:justdave]]

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)

Comment 3

[Dave Miller [:justdave]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Dave Miller [:justdave]]

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

Comment 6

[Dave Miller [:justdave]]

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.

Comment 7

[Dave Miller [:justdave]]

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.

Comment 8

[Dave Miller [:justdave]]

Attachment: 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 9

[Bradley Baetz (:bbaetz)]

Comment on attachment 100971 [details] [diff] [review]
change "attachment" to "inline"

This sucks....

r=bbaetz x2, if bz thinks it works :)

Comment 10

[Dave Miller [:justdave]]

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 11

[Boris Zbarsky [:bzbarsky]]

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 12

[Boris Zbarsky [:bzbarsky]]

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 13

[Boris Zbarsky [:bzbarsky]]

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 14

[Boris Zbarsky [:bzbarsky]]

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 15

[Boris Zbarsky [:bzbarsky]]

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 16

[Boris Zbarsky [:bzbarsky]]

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 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Dave Miller [:justdave]]

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.

Comment 19

[Dave Miller [:justdave]]

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

Comment 20

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

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?

Comment 21

[Dave Miller [:justdave]]

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

[Jesse Glick]

Related: bug #185618