131834 - We should not fetch part we cannot display with mime_parts_on_demand

Status: RESOLVED WONTFIX

(MailNews Core :: Networking: IMAP, defect)

Description

[Jean-Francois Ducarroz]

This has been extracted from bug 128888. I have a message which the body is a
PDF documment. When I click on the message, it takes a long before we display
the (empty) message. We should not fetch the PDF data during a message display.

Comment 1

[Jean-Francois Ducarroz]

The fix is the following:

Index: src/nsIMAPBodyShell.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/imap/src/nsIMAPBodyShell.cpp,v
retrieving revision 1.32
diff -u -2 -w -r1.32 nsIMAPBodyShell.cpp
--- src/nsIMAPBodyShell.cpp	15 Jan 2002 00:43:07 -0000	1.32
+++ src/nsIMAPBodyShell.cpp	16 Mar 2002 01:51:56 -0000
@@ -928,6 +928,12 @@
 
	// message), and that message should be inline, then its body
 
	// should inherit the inline characteristics of that message
+    // but only it's a text part
 
	if (m_parentPart->GetType() == IMAP_BODY_MESSAGE_RFC822)
+    {
+
		if (!PL_strcasecmp(m_bodyType, "text"))
 
		return m_parentPart->ShouldFetchInline();
+      else
+        return PR_FALSE;
+    }

but that will cause a regression as in the response parser, we will not
correctly detecting we are generating a message and not just fetching headers.
This because the actual code expect we always have to fetch message body which
is not true anymore.

We need to reset fDownloadingHeaders after calling msg_fetch_headers.

Comment 2

[Jean-Francois Ducarroz]

Attachment: Test case

Comment 3

[Wayne Mery (:wsmwk)]

is this still reproducible?

Comment 4

[rsx11m]

It's difficult to tell. The 36KB test message is just above the 30k threshold given in mail.imap.mime_parts_on_demand_threshold which I'd assume applies in this case, but it's too small to figure if the whole message is downloaded.

I'll try with a similarly structured message, but of a few MB, which should be conclusive. It needs to be hand-crafted though as Thunderbird/SeaMonkey itself can't produce something like this.

Comment 5

[rsx11m]

Yes, this is still reproducible on current trunk nightlies with the structure provided in attachment 74816 [details], but not with multipart/mixed message.

Test conditions:
 - indexing and offline synchronization are not active
 - disk cache is disabled, memory cache is enabled
 - mail.biff.show_alert and mail.biff.alert.show_* are "false"
 - mail.server.default.mime_parts_on_demand is "true"
 - mail.imap.mime_parts_on_demand_threshold is default 30000
 - message is smaller than size of memory cache

Test cases:
(1) multi-part structure:
  multipart/mixed
    text/plain
    application/pdf

(2) single-part structure"
  application/pdf

Case (1) shows the desired behavior, only the short text part is loaded and displayed, whereas the PDF is only downloaded when opened or the message is copied. This is regardless of the View > Display Attachments Inline setting.

Case (2) shows the behavior mentioned in the bug description, the entire message is downloaded on initial opening, then the attachment shown in the
pane as the only content.

So, this bug is still valid though I don't know how frequently a stand-alone attachment is met in real life. Most if not all e-mail clients will introduce just an empty text/plain MIME part before the actual attachment.

Comment 6

[Wayne Mery (:wsmwk)]

Is there value in changing how this works?

Comment 7

[gene smith]

I've never seen an email with a binary attachment as the top level body. However, from what I can tell, it is supported here:
https://searchfox.org/comm-central/rev/1480d9f14070fee52641c2698fc9a104b02ceddb/mailnews/mime/src/mimemoz2.cpp#124
(I assume "friends to the north" == microsoft.)

When I open the attached email, the whole thing is fetched and stored to cache. I guess the reporter would prefer to have only the header fetched and then the pdf body fetched when the attachment link is clicked.
However, per Kai's recent comment here (bug 1675914 comment 8) it looks likely that fetching a single part of a message is a lost cause anyhow. So don't see any reason to address this issue.

Comment 8

[Magnus Melin [:mkmelin]]

I think we can mark this wontfix.