The default bug view has changed. See this FAQ.

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

NEW
Unassigned

Status

MailNews Core
MIME
15 years ago
4 years ago

People

(Reporter: Rich Renomeron, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
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...

Updated

15 years ago
QA Contact: olgam → trix
(Reporter)

Comment 3

15 years ago
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

15 years ago
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"?
QA Contact: trix → stephend

Comment 5

14 years ago
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

14 years ago
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

14 years ago
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.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All

Comment 8

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

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

Comment 13

13 years ago
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

13 years ago
(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.
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.
Product: Browser → Seamonkey

Comment 16

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

Updated

12 years ago
Assignee: sspitzer → mail

Comment 17

11 years ago
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

11 years ago
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.
Component: MailNews: Main Mail Window → MailNews: MIME
Keywords: helpwanted
Product: Mozilla Application Suite → Core

Updated

10 years ago
Assignee: mail → nobody
QA Contact: stephend → mime
should be marked enhancement, and summary amended to match?
Summary: JPEG Attachments displayed inline even if content-disposition set to attachment → if view | attachments inline JPEG Attachments displayed inline for content-disposition set to attachment
(Assignee)

Updated

9 years ago
Product: Core → MailNews Core

Comment 20

8 years ago
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

5 years ago
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.  
----
You need to log in before you can comment on or make changes to this bug.