147461 - if view | attachments inline JPEG Attachments displayed inline for content-disposition set to attachment

Status: NEW

(MailNews Core :: MIME, defect)

Description

[Rich Renomeron]

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.

Comment 1

[Rich Renomeron]

Attachment: rfc/822 message with non-inlined JPEG attachment

This message also has multipart/alternative sections, if that is helpful.

Comment 2

[Boris Zbarsky [:bzbarsky]]

See bug 98360 also...

Comment 3

[Rich Renomeron]

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

Comment 4

[Stanimir Stamenkov]

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"?

Comment 5

[Karsten Silkenbäumer]

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.

Comment 6

[Stanimir Stamenkov]

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.

Comment 7

[Mike Cowperthwaite]

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.

Comment 8

[Stanimir Stamenkov]

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.

Comment 9

[Olli Männistö]

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

Comment 10

[Olli Männistö]

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. 

Comment 11

[Mike Cowperthwaite]

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.

Comment 12

[Mike Cowperthwaite]

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

Comment 13

[Mike Cowperthwaite]

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?)

Comment 14

[Stanimir Stamenkov]

(In reply to comment #13)

> Maybe the best thing to do with this menu would be to make it a submenu,

It is better to keep this option simple as it is now (just one). There's only
need to correct its behavior and most probably change its label.

> 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?)

The "VCard" is one I've thought of. The preference to "Disable Plug-ins for
Mail&News" should be all one may need. All internal types should be shown
whenever appropriate and if the option this bug is about become stg like "Don't
display multi-parts" - not checked.

There may are times when an internally handled type is not appropriate to
show/execute, like "text/javascript". JavaScript may be either suppressed -
there's already an option, or it could be hardcoded not to execute such most
probably unsafe parts.

Functionality like "Don't display images", etc. should go with the "View ->
Message Body As" options and other places.

The thing with not showing inline parts is more about the ability not to fetch
the whole message (from an IMAP, for example) to show its body/first part - this
is what this bug should focus on, IMHO.

Comment 15

[WADA:World Anti-bad-Duping Agency]

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.

Comment 16

[Mike Cowperthwaite]

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

Comment 17

[Lee_Dailey]

howdy y'all,

[1] 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

[2] 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?

[3] obligatory painfully obvious comment = this problem exists in tb15.

take care,
lee

Comment 18

[David :Bienvenu]

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.

Comment 19

[Wayne Mery (:wsmwk)]

should be marked enhancement, and summary amended to match?

Comment 20

[Charles]

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.

Comment 21

[Evan Lavelle]

Bump. It's been 10 years since this was filed, and TB 12.0.1 *still* has this problem. Is this a record? 

RFC2183 is explicit; see the extracts below. It's plain wrong to automatically display an attachment which is marked 'Content-disposition: attachment'. The user must instead take "some further action". The 'display Attachments Inline' checkbox isn't enough, because (a) it's on by default, and (b) it also applies to attachments which are *intended* to be inline (2.1).

Here's why this is a problem. I automatically email out html attachments. These are primarily JavaScript and SVG files, and MUAs can't hope to render them. So, I don't want them to even try, because they'll end up showing some pointless and arbitrary text extracted from some random part of the page. There's a perfect answer to this: a MIME-compliant MUA won't try to render a 'Content-Disposition: attachment'. Outlook gets this right, TB doesn't.

=========================================================================
RFC 2183:

----
2.  The Content-Disposition Header Field

   Content-Disposition is an optional header field. In its absence, the
   MUA may use whatever presentation method it deems suitable.

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

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