55657 - Possibility to disable Display inline attachments

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Bernd Mielke]

In Nav4.6 there was a menu entry to disable the the display of inline
attachments (in the view menu). I miss this button in mozilla. If somebody sends
you a drawing as dxf it will be rendered instead of beening a pure attachment
because it is a text document.

win98 20001007

Comment 1

[Len Trigg]

I think this is particularly important if you're using imap mail, since the
mail.imap.mime_parts_on_demand pref ignores those attachments that are being
viewed inline.

Thus if someone sends you a bunch of frigging huge html/text/jpg attachments,
mozilla tries to display them. No attachment icon/menu appears until after the
message has downloaded, so you're buggered :-).

What happens if you just set the mail.inline_attachments pref to false? :-)

Comment 2

[scottputterman]

nominating mail3 and reassigning to sspitzer

Comment 3

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8.

How hard will this be to do? Adding mscott and rhp to find out why we haven't
done this so far.

Comment 4

[scottputterman]

reassigning to ducarroz

Comment 5

[scottputterman]

moving to mozilla0.9

Comment 6

[scottputterman]

marking nsbeta1-

Comment 7

[Keyser Sose]

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

Comment 8

[Mike Young]

What is the status of this bug? It looks as if it may have fallen off of
people's radars.

This is not an enhancment, because it means that large IMAP attachments
essentially  prevent you from reading the message until they are downloaded.

Comment 9

[Mike Young]

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

Comment 10

[Matthias Versen [:Matti]]

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

Comment 11

[juha0]

Anything happening to this one? This behaviour is really painful e.g. when using
slow connection with IMAP server. Prevents you reading messages with large
attachments at all.

Comment 12

[[not reading bugmail]]

yeah, the perf is working in the file.. just no menu item.  Besides this is on
the future radar and not set for any milestone.

Comment 13

[scottputterman]

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

Comment 14

[Ivan Tarapcik]

Some notes on this: (build 20020122)

- mozilla displays text/plain (may be other) attachment inline even if Content-
Disposition: attachment;

- I would appreciate if mozilla can display attachment inline based on size. It 
is fine, if I can view 2kB readme.txt inline, but it sucks, if displaying 14MB 
logfile.txt freezes whole MailNews

Comment 15

[hans_k_97]

I send around a lot of XML documents which are forcibly inlined (and therefore
show up as unreadable junk on the receiver end).

This is a major usability issue for me.

Comment 16

[Ben Bucksch (:BenB)]

Dennis, which pref is that?
Everyone else (with a slow IMAP connection): Please test that pref.
Adding a menu item should be trivial, if the pref works reliably.

Comment 17

[[not reading bugmail]]

I think I was refering to the one listed here, that doesn't do anything... I'll
take a look to see I copied it down somewhere, but it might be some before I
find anything.

Comment 18

[[not reading bugmail]]

I couldn't find anything on my computer but I just did find inline_attachment
info in bug 32767.. 

Comment 19

[Bernd]

please reconsider the nsbeta marking it was working in NN4xx. And
http://slashdot.org/comments.pl?sid=29319&cid=3146404 shows the bad press we get
not fixing this.

Comment 20

[Ben Bucksch (:BenB)]

Bernd, what you quote is not at all related. HTML can appear in the body as
well, disabling attachments buys you *nothing*. In you fully read the page you
referenced, you see links to bugs that do apply.

Comment 21

[[not reading bugmail]]

Ben,

read this comment http://bugzilla.mozilla.org/show_bug.cgi?id=32767#c8, bienvenu
says to adjust both perfs for this to work..  if not, there was sometime ago,
many perfs were wiped away that were un-used (to get rid of, and drop confusion
from users when trying perfs..) around late november or early december '01, when
the perf file problem came in.

Comment 22

[Jesse Ruderman]

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

Comment 23

[Michael Buckland]

Discussed in Mail News bug meeting with Engineering, QA, Mktng and PjM. 
Decision was to minus this bug.

Comment 24

[jglick]

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

Comment 25

[Matthias Versen [:Matti]]

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

Comment 26

[charles allen]

If this is not the same bug as "Possibility to disable Display inline
attachments" let me know & I'll enter a new one.  I had a hard time finding this
bug because it's listed under Mail Window Front End!  What does it have to do
with the front end?  I think it makes MUCH more sense for this to be listed
under COMPONENT: Attachements.  Shouldn't OPSYS be ALL instead of OTHER? 
Shouldn't Platform be ALL rather than PC?  This bug seems to be seriously
miscataloged!

Using Mozilla 1.0 MailNews on Solaris.  Using SMTP/POP email.  I attach multiple
text files to an email, and type a brief message explaining their contents. 
MailNews shows me the two files as attachments.  I send the message.  On MS
Windows using Eudora and SMTP/POP email, I get no attachments!  The multiple
text files are concatenated together in one long message body!  YUCH!  There is
not even a break in between the two attached files!  Is this the same bug as
described above?  Is there a preference I'm overlooking to prevent text
attachments from becoming inline?  

Forcing attachments to be inline WILL prevent me and my users from using Mozilla
MailNews!  I see this as a critical function!  HELP!  Can someone increase the
severity of this bug?

Here are the headers.  The short note is "Here's the latest ..."  The first
attached file begins with "Jun 10" and there should be a header before it
indicating that.  I cut the remainder of the long message out.  I've replaced
system names, IPs, and email addresses with '_' for privacy.

X-Time: <200206101758.g5AHwhg25254>
Return-Path: <_>
Received: from clemson.edu (_)
	by CLEMSON.EDU (8.11.4/8.11.4) with ESMTP id g5AHwhg25254
	for <_>; Mon, 10 Jun 2002 13:58:43 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 10 Jun 2002 13:58:43 -0400
From: _
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1a) Gecko/20020606
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: _
Subject: _
Content-Type: multipart/mixed;
 boundary="------------050400060608060502090504"

here's the latest messages along with patching from /var/adm
on the sunblade 1000 'lily'


Jun 10 10:46:13 lily reboot: [ID 662345 auth.crit] rebooted by root
Jun 10 10:46:13 lily xntpd[246]: [ID 866926 daemon.notice] xntpd exiting on
signal 15
Jun 10 10:46:13 lily syslogd: going down on signal 15
J

Comment 27

[Mike Young]

This bug is in the Front End component because there was/is? a backend for
inline attachments. All that needs to be done now is to have the front end
hooked up. 

Changing platform and OS to all, and adding mozilla1.2 keyword to get this
looked at. If the backend does exist, this should be a fairly simple fix. If it
doesn't, then we'd probably have to push it back a little farther while the
backend is worked out.

CCing bienvenu because of his comment in bug 32767 comment 11 that
"mail.inline_attachments is obsolete"

Charles,
I'm inclined to believe that this bug is not the problem you are describing.
Inline attachments in the context of this bug are on the receiving end. Since
you are receiving through eudora you are having a problem with mozilla _sending_
inlined attachments. 

Comment 28

[David :Bienvenu]

I was told that mime didn't support this anymore. But JF should know.

Comment 29

[Jean-Francois Ducarroz]

Mime does not support that anymore but it would be easy to restore it as it is
much simpler than it was in 4.x

Comment 30

[charles allen]

Thank You Mike Young.  I entered a new bug for needing to send email with
attachments NOT being inline.  Turns out there is a user_pref to turn on the
behavior I want, but no GUI way of doing it that I know of. 
FYI here it is:  bug #151256 

Comment 31

[R.K.Aa.]

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

Comment 32

[R.K.Aa.]

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

Comment 33

[Daniel Wang]

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

Comment 34

[Charles Cooley]

There is an excellent discussion about this over in bug 98360 especially the
quotes from the relevant RFCs in comment seven.  

Mozilla's current behavior is in violation of RFCs 1806 and 2183.

Not only does Mozilla force us to view images marked "inline" it also displays
all image "attachments" inline which is NOT appropriate for that Content
Disposition.

Given the 4xp status, IMAP performance hit, and the fact that this is a
violation of the relevant RFCs, I think the severity should be bumped a little
higher.

Did I mention, it's been fixed over in the *BROWSER* component?  (bug 98360)

Comment 35

[Jean-Francois Ducarroz]

I aggree, we should giv ethe user the option to display (inline) or not inline
parts and/or attachment parts. I'll see if I have time to implement that for 1.3

Comment 36

[Trix Supremo]

changin qa contact to yulian

Comment 37

[Jean-Francois Ducarroz]

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

Comment 38

[Jean-Francois Ducarroz]

the pref name for this feature should be "mail.inline_attachments" like in 4.x.
This is a boolean

Comment 39

[Jean-Francois Ducarroz]

Attachment: Preliminary patch, v1

First implementation of the UI: added a View attachment Inline under the
mail3Pane window View menu.
First Implementation of the support of this feature in Mime. I still need to do
intensive testing.
Missing: Imap part of this feature. Imap need to not fetch part that are
normaly displayed inline when not needed.

Comment 40

[Ben Bucksch (:BenB)]

UI Suggestion: Make a submenu Attachments. This would match the "Headers" and
Body ("Message Body As") submenus. It would currently contain one menuitem only,
but that may change in the future. In any case, it would much more logical to
me. I'd also add a separator before Headers to stress that these 3
submenus/items apply to the message (pane), while the 2 above ("Sort As" and
"Messages") apply to the thread (pane).

Comment 41

[robinf]

+<!ENTITY inlineAttachmentMenu.label "View Attachment Inline">

Suggested wording for View menu item: "Display Attachments Inline"

Comment 42

[jglick]

>Suggested wording for View menu item: "Display Attachments Inline"
I agree.

Thanks for fixing the conflicting mnemonic for "Message Body As". :-)

>Make a submenu Attachments. ... It would currently contain one menuitem only,
I'd leave it as a single menu item until if/when it has more items.

>I'd also add a separator before Headers to stress that these 3 submenus/items 
>apply to the message (pane), while the 2 above ("Sort As" and "Messages") apply 
>to the thread (pane).

I agree the separator would be good.

Show/Hide --->
--------------------------
Sort by --->
Messages --->
---------------------------
Headers ---> 
Message Body As --->
Display Attachments Inline
---------------------------

Comment 43

[Jean-Francois Ducarroz]

Attachment: Preliminary patch, v2

I updated the UI to Jenifer last proposition. This patch also include IMAP
modification. I still have some trouble with IMAP when displaying attachment as
link (in the chrome): It refuse to provide the content when fetching some
part...

Comment 44

[Jean-Francois Ducarroz]

The problem I have is with message with embedded image (multipart/related). When
the option "Display Attachments Inline" is turn off, they are not showing up at
all, not even has attachment. In some case neither does the message body. In
fact, 4.x has the same bug!

My guess is that the problem is caused by the fact we are not generating IMAP
url for the related part like we do for regular attachment. That also explain
why we download n time the whole message when displaying a email with n embedded
images (View Attachments Inline on) instead of downloading n time just the
needed part.

Comment 45

[Jean-Francois Ducarroz]

Attachment: Proposed fix, v1

This patch is complete and fix problem with multipart/related already present
in 4.x. The modifications in mime and imap come from 4.x except for the bug
fix:

- Accepting to display the first part of multipart/related even if this one
(the parent) is the second part in the message. This is the case where a we
have a multipart/related embedded into a multipart/alternative.

- We have a mix up between &part= and ?part= which cause several troubles. I
cleaned up that by generating a valid url (use ? first and then &) and also,
imap look for both case now.

Comment 46

[Cavin Song]

Comment on attachment 106459 [details] [diff] [review]
Proposed fix, v1

r=cavin. But in GetShowAttachmentsInline(), make sure argument ‘aResult’ is
not null before referencing it.

Comment 47

[Jean-Francois Ducarroz]

Attachment: Proposed fix, v2

Addressed Cavin's comment

Comment 48

[Jean-Francois Ducarroz]

Comment on attachment 106715 [details] [diff] [review]
Proposed fix, v2

carry over R=cavin

Comment 49

[David :Bienvenu]

+
+  if (GetShowAttachmentsInline())
 	SetContentModified(IMAP_CONTENT_MODIFIED_VIEW_INLINE);
+  else
+    SetContentModified(IMAP_CONTENT_MODIFIED_VIEW_AS_LINKS);
can we just use the ? operator here:

+    if (m_protocolConnection)
+      m_showAttachmentsInline = m_protocolConnection->GetShowAttachmentsInline();
+    else
+      m_showAttachmentsInline = PR_TRUE;

m_showAttachments = !m_protocolConnection ||
m_protocolConnection->GetShowAttachmentsInline();

+  *aResult = PR_TRUE; // true per defaul
typo - should be default

+{
+  PRBool rv = PR_TRUE;
+  if (m_imapMessageSink)
+    m_imapServerSink->GetShowAttachmentsInline(&rv);
+  return rv;
+
we tend to use rv for nsresults. Can you change this var name to
"showAttachmentsInline?

other than that, it looks OK. I think this needs lots of testing. Have you made
sure that things like save attachment works, etc? I'm worried about this change,
for example:

   PL_strcat(result, imappart);
-  PL_strcat(result, "&part=");
+  PL_strcat(result, "?part=");

We might have some (bad) code that's looking for &part, for example.

Comment 50

[Jean-Francois Ducarroz]

Attachment: Proposed fix, v3

I have addressed bienvenu's comment. I have carefully tested the patch in
various situations especially opening and saving imap attachments and imap
embedded object like images. Works great.

About the change from &part to ?part, I looked at lxr and there was only one
spot where we don't check both cases and this is in
/mailnews/imap/src/nsImapUrl.cpp, line 443 which I have changed in this patch.

Comment 51

[Jean-Francois Ducarroz]

Comment on attachment 106970 [details] [diff] [review]
Proposed fix, v3

carry over R=cavin

Comment 52

[David :Bienvenu]

Comment on attachment 106970 [details] [diff] [review]
Proposed fix, v3

sr=bienvenu, but
+  // Enforce the invariant that any chached shell we use
fix this typo - "cached"

Comment 53

[Jean-Francois Ducarroz]

Fix checked in

Comment 54

[Bernd]

YOU made my day, thanks a lot. I can't verify on all platforms, but it works as
intended on win98

Comment 55

[Jean-Francois Ducarroz]

This fix has cased the crash bug 181856

Comment 56

[[e-mail]]

Comment on attachment 106970 [details] [diff] [review]
Proposed fix, v3

>Index: base/resources/content/mailWindowOverlay.js
>===================================================================
>RCS file: /cvsroot/mozilla/mailnews/base/resources/content/mailWindowOverlay.js,v
>retrieving revision 1.146
>diff -u -4 -w -r1.146 mailWindowOverlay.js
>--- base/resources/content/mailWindowOverlay.js	20 Nov 2002 11:49:10 -0000	1.146
>+++ base/resources/content/mailWindowOverlay.js	21 Nov 2002 01:34:00 -0000
>@@ -172,8 +172,12 @@
>   if (threadColumn && thread_menuitem){
>       thread_menuitem.setAttribute('checked',threadColumn.getAttribute('currentView')=='threaded');
>   }
> 
>+  // Initialize the View Attachment Inline menu
>+  var viewAttachmentInline = pref.getBoolPref("mail.inline_attachments");
>+  document.getElementById("viewAttachmentsInlineMenuitem").setAttribute("checked", viewAttachmentInline ? "true" : "false");
>+
>   document.commandDispatcher.updateCommands('create-menu-view');
> }
> 
> function setSortByMenuItemCheckState(id, value)
>@@ -1365,8 +1369,17 @@
>     gPrefs.setIntPref("mailnews.display.disallow_mime_handlers",
>                       disallow_classes_no_html);
>     MsgReload();
>     return true;
>+}
>+
>+function ToggleInlineAttachment(target)
>+{
>+    var viewAttachmentInline = !pref.getBoolPref("mail.inline_attachments");
>+    pref.setBoolPref("mail.inline_attachments", viewAttachmentInline)
>+    target.setAttribute("checked", viewAttachmentInline ? "true" : "false");
>+    
>+    MsgReload();
> }
> 
> function MsgReload()
> {

Nit: you don't have to set the checked attribute on the target because you have
to do it again in view_init() anyway.