Open Bug 339834 Opened 18 years ago Updated 2 years ago

"This body part will be downloaded on demand" is confusing -- improve text

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: dada_lope, Unassigned)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: 1.5.0.2 (20060308)

I recently saw this message in an email, mistook it for a possible virus signature, and replied to the author asking for confirmation, CC to all. (I wanted to intercept the others, lest they get infected.) I was very embarrassed to discover that the provocative message came from my own Thunderbird client. The author's own prose in the same email was suppressed (invisible); otherwise I would have recognized his voice and looked for a local explanation for the "body part" message. Instead this lone peculiar phrase made it seem unlikely that the author had composed the email himself. This phrase is unnecessarily cryptic and should be replaced with a message that succinctly, plainly, and accurately describes the trouble or trigger and possible options for its resolution.
This request is independent of other requests I see, which take issue with the conditions under which this message appears, or the lack of an effective response.

Reproducible: Didn't try

Steps to Reproduce:
1. Email was sent from Apple Mail, with a plain text letter, followed by a PDF attachment, followed by an empty plain text section.
2. Open it in a separate window, via IMAP
3.

Actual Results:  
First time, the plain text letter was invisible. All I saw was the message "This body part will be downloaded on demand" and two attachments (the PDF and the "Part 1.3" empty text block that followed it). After the author disavowed the cryptic message, I listed the message source and found his prose. Then I tried "Display attachments inline", which had been unchecked. Immediately his prose appeared in the message window, and "This body part will be downloaded on demand" did not. This email has never again displayed in the original problem state. I have not received other such emails yet -- it was only yesterday.

Expected Results:  
Show me the prose always. Show me the message if it tells me plainly something I can do.
See the potential workaround at bug 149771 comment 31 -- if that works for you, please mark this bug as a dupe of that one.
(In reply to comment #1)
> See the potential workaround at bug 149771 comment 31 -- if that works for 
> you, please mark this bug as a dupe of that one.

Thanks, that's very close to the symptoms I experienced, but No, this is not a duplicate of that. 

I read the entire thread, and the various symptoms appear closely related to mine, though different from mine and from each other. (My plain-text message didn't appear, and the attachments did. Some others had that experience, but others lost their attachments also or instead.) I would prefer never to see those symptoms again, so I guess I'll change MPOD as directed in comment 31 and see if I can tolerate the expected slowdown.

But the thrust of my complaint is the message itself. When this mystery is triggered, it should say, for example, 
>    Mozilla is struggling to find and handle some sections and attachments
>    of this message. Try
>       * enabling/disabling 'View attachments inline', 
>       * viewing the message source, or
>       * forwarding this message to yourself.
>    Also see https://bugzilla.mozilla.org/show_bug.cgi?id=149771#c31
That would tell me (a) it's Mozilla talking, not my colleague or his hypothetical email virus; and (b) Here are some things you can do that have affected the symptoms for other people. A spiffy thing would be to snatch some recent data about the message, including the header, the section sizes, and the IMAP conversation that delivered it; and then ask the user's permission to ship them to Mozilla.org. It's a way to help collect some raw data on the spot, to feed your study of the cause. (When I get in trouble programming, often printf is my savior. I'm not a very good programmer. But this would be like that.)

The problem with the current "body part" message is that it only makes sense to the Mozilla "in" crowd, and it doesn't point to any action from me that might help. The term "body part", though benign and technical in this context, and to me pleasingly edgy, has a macabre connotation everywhere outside this community. It seems dramatically out of place, for both emails from friends and error messages from software. This is a major part of what triggered *my* misplaced concern about a virus.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Summary: "This body part will be downloaded on demand" is confusing and unhelpful → "This body part will be downloaded on demand" is confusing -- improve text
Version: unspecified → Trunk
QA Contact: front-end
Assignee: mscott → nobody
May I suggest 

"Portions of this message will not be displayed until downloaded"

The "body part" message is gruesome. Simply changing the text is a good start.

But the real underlying issue is that the text becomes part of the body of the message, instead of an alert (dialog box or popop) or a chrome element (a "download whole message" button) - it's not clear that this is a message *from thunderbird*. I just got a response from someone asking what I meant about the "body part" comment.
That proposed text is indeed an improvement.

I also agree with the final paragraph about making it obvious the message is from Tbird. Perhaps one solution is something similar to Internet Explorer's warnings for active content -- a yellow bar across the top of the window, a warning that invites you to click on it, and a drop down menu with possible actions.
I also see thunderbird 3.0b3pre sometimes displaying a message (from IMAP) before it was fully downloaded. It then displays that the messagebody will be downloaded when needed upon demand, but doesn't do so - I expect because it already thinks it has cached the full message. There is no way to "reload" it. Only chance: Move message via webmail, go to that folder and tbird will think the message is new and redownload.

There seems to be something terribly broken. What makes tbird think that (I assume) when a download of a message failed it still marks it as "has been cached fine"?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.