From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 BuildID: 2002052319 Mozilla seems to be ignoring the content-disposition header on received messages when JPEGs are involved. As covered in bug 55657 and others, this causes Mozilla to wait for the entire message to be downloaded before displaying anything. This can be a pain when someone insists on sending multiple 300 dpi photo scans at you via Outlook Express. Unfortunately, since OE seems to set content-disposition: attachment on the JPEGs, I don't think I can blame MS for it ... Since this bug involves Mozilla ignoring a header in a message, I believe it's a separate issue from 55657, which covers disabling inline attachments. Reproducible: Always Steps to Reproduce: 1. Receive message with large JPEG attachment(s) 2. Open message 3. Wait for everything to be downloaded.
Created attachment 85205 [details] rfc/822 message with non-inlined JPEG attachment This message also has multipart/alternative sections, if that is helpful.
See bug 98360 also...
I have also observed this behavior on Mozilla 1.0.0 (Gecko/20020609) installed via the Red Hat RPMs, and on the 1.1a Linux Build (Build ID: 2002061108).
I've played with the 'Content-Disposition' header and it seems that Mozilla Mail ignores it completely. It takes only the 'Content-Type' into account and if it is some of 'text/plain', 'text/html', 'image/gif', 'image/jpeg' and so on "basic" types it displays these parts inline no matter if the 'Content-Disposition: attachment'. Types like 'application/octet-stream' are not displayed inline even if 'Content-Disposition: inline'. I suppose if the 'Content-Disposition: inline' but the type could not be handled to be previewed inline to act like attachment, just then. And every 'Content-Disposition: attachment' or unknow value to be treated as attachment. Should someone change the status of this bug to "NEW"?
I have also observed this behaviour in Mozilla 1.3=Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.3) Gecko/20030312. Opening an email with one part being Content-Disposition: attachment Content-Type: text/csv or Content-Type: text/comma-separated-values shows up the whole file inline. The mail is multipart/mixed, the first being multipart/alternative (with text/plain and text/html), ans the second is a csv-file.
So there should be "Do not display inline attachments" (other than the first part) option instead of "Display Attachments Inline" (under the "View" menu) and when this option is not checked only attachments marked "inline" should be displayed. When this option is checked no attachments would be shown inline (after all this is what Bug 55657 was for). If there's an inline part/attachment of PDF (for example) type and plugins are not enabled for Mail & News, such should be treated as "attachment". When plugins are enabled for Mail & News but there's no plug-in for handling PDFs a helper application should popup opening the attachment from/stored in temporary file/place on the disk. The proper handling of multipart MIME messages (there are many other features which would be nice to be handled, like auto-selecting the proper part of a multipart/alternative message with 'Content-Language' set on the different parts, etc.) is very important and such basic functionality meant by the 'Content-Disposition' header should work smoothly and without the current quirks.
Ref: Content-disposition is covered by RFC 2183 (superceding RFC 1806): http://www.faqs.org/rfcs/rfc2183.html Confirming, but reducing severity to Normal. OS, Platform => All. I think Stanimir's idea for changing the menu makes sense.
Clarification to my Comment 4: The line starting with: helper application should popup opening the attachment should read: helper application should popup (automatically when previewing the message) opening the attachment Some additions: The current behavior probably tolerates the old style messages where the attachments are uuencoded in the message body and they have no attributes like 'Content-Disposition'. One possible solution/behavior is to treat the attachments in such messages to have 'Content-Disposition: attachment' always. Of course there could be left the old option "Display Attachments Inline" (in addition to the new proposed one, see my Comment 4) but this one would/should work only for this type of messages (uuencoded) and will uncessary complicate the UI in vafor of some deprected format.
With imap the aggravation is doubled - 1st you have to wait for a long time for the message to display. Then, every attachment is re-downloaded when you use "save" or "save all".
Just today I got 12MB of digital camera images, thunderbird and mailnews were unable to download and display the message in 20 minutes using the company 10Mbps net.access. Web frontend for the mailserver let me download the whole bunch in under a minute.
Olli Männistö, I believe you need to find a different bug. This bug is about a very specific issue, unrelated to re-downloading (bug 46233) or slow downloading.
*** Bug 168668 has been marked as a duplicate of this bug. ***
See bug 229075. Maybe the best thing to do with this menu would be to make it a submenu, maybe something like: View Attachments Inline > ( ) All (x) As specified in message ( ) None -------- [x] Images The 'Images' checkbox would allow display of inline image/* types to be suppressed while still allowing text/* and message/rfc822 attachments to be shown inline. (Are there other attachment types that can be displayed natively?)
I vote to idea by Mike Cowperthwaite in Comment #13. But I think including all options in View menu is difficult. How about adding "Customize" option to attachment display options like Character Coding? I love current simple flip/flop option too. So my proposal is as follws. (A) View menu structure - View - Attachments - Display all attachments inline if diaplayable, or display all attachments as attachment. (Flip/Flop, Same as current option setting) - Cutomized-option-1 - Cutomized-option-2 | - Cutomized-option-N ==================== - Cutomize ==================== - Other view options (B) Customization panel (Helper Application definition like) Content-Types are specified by user like Helper Application. User option is applied like Message Filter. - if matched, then stop further matching. (Note: # indicates my favarites) 1) text/plain #Always Inline, Always Attachment or Content-Disposition base. 2) text/html Always Inline, #Always Attachment or Content-Disposition base. 3) image/jpeg, image/png Always Inline, Always Attachment or #Content-Disposition base. 4) application/ms-word ### DELETE AND SEND IT BACK TO SENDER NINE TIMES. 5) message/rfc822 #Always Inline, Always Attachment or Content-Disposition base. If inline, Inline or #Attachment for nested message/rfc822 6) multipart/alternative Order of selection - #Normal(last first) or Reversed(first first). Display all of parts in multipart/related or #NOT. 7) text/*, image/*, application/* etc. Always Inline, #Always Attachment or Content-Disposition base. 8) Others Always Inline, #Always Attachment, Content-Disposition base, etc.
*** Bug 290019 has been marked as a duplicate of this bug. ***
howdy y'all,  my tb info ... Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 - Build ID: 2005120115  REQUEST = change "Product" from "mozilla application suite" to "core" since th following tbird bug ... - Attachments with "Content-Disposition: attachment" shows automatically https://bugzilla.mozilla.org/show_bug.cgi?id=290019 ... was duped to this one, shouldn't this bug be "core" now?  obligatory painfully obvious comment = this problem exists in tb15. take care, lee
for historical reasons, this is done intentionally and has been since Netscape 2.0 and Mozilla 1.0...we display inline the attachments we know how to display unless you turn off view | attachments inline. Perhaps we could add a pref for respecting the content-disposition for all attachment types.
should be marked enhancement, and summary amended to match?
Also, some kind of sane 'max_size' setting, so vCards, and small email signature graphics will display, but large pictures from Aunt Susans last vacation won't.