Closed Bug 190905 Opened 21 years ago Closed 20 years ago
[MIME] "This body part will be downloaded on demand"
32.91 KB, text/plain
79.70 KB, text/plain
17.06 KB, text/plain
138.00 KB, text/plain
17.28 KB, text/plain
3.28 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030125 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030125 Since I switched from POP3 to IMAP, I get the following message in the body of the some of the email messages: "This body part will be downloaded on demand". I cannot figure out a common attribute amongst email messages that cause this message. My solution has been to forward the message to myself in order to view the body of the message. I would be great if someone can take a look at this problem. Reproducible: Sometimes Steps to Reproduce: 1. receive a message (I think all of them that cause the problem have attachments) 2. 3. Actual Results: Only displays "This body part will be downloaded on demand" in the body of the message Expected Results: Show the body of the message.
can you attach a message that exhibits this problem, or send it to me? Also, what view | message body as setting do you have? I've never seen this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have been finding this problem with IMAP mail also. It seems to be possible, at least usually, to get the message body to display by cycling among the "view |message body as" options. Once the message body does display, it stays there for all the "view | message body as" choices. I originally thought this problem began when I checked the "Mail & Newsgroup Account Settings|<acct name>|Offline and Disk Space| Do not download locally messges that are larger than 50KB" option. With that option checked, it may happen even when there is no attachment. But today it has been happening (using build 2003020608) without the 50KB option checked on some emails that have attachments. (Mine is an NT 4.0, SP6, system.)
I get this frequently. Reading message source, I'm seeing two patterns: 1) Messages sent from Outlook Express 6.0 seem to get this frequently. 2) The text section is mostly (always?) quotable-printable. 3) The mime headers are set up different from those used by Mozilla Messenger I'm guessing that the quoteable/printable piece is what's screwing up MM 1.3b. If a setting for this still exists in MM, I'll see if I can reproduce this that way.
I think I've got it. It's one of the mail headers. The following fragment of a header is from a message that exhibits the problem: Subject: Fw: Columbia Astronaut, Ilan Ramon defeated Saddam Hussein's first att\empt to acquire Nuclear Weapons in 1981 Date: Wed, 26 Feb 2003 09:55:46 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary=----="_NextPart_000_0006_01C2DD7D.3C0D4BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Note that the boundary line puts the MIME label ("_NextPart...") in double quotes. That appears to be what's tripping up Messenger. If I edit the message and removed the double quotes, *the message renders correctly*. Hopefully this explains the problem.
from rob's last comment, this might be a mime bug. gail (and lori) have started seeing this with messages sent with attachments. it sounds like she[s see it from messages from mailers like: "X-Mailer: Apple Mail (2.552)" "X-Mailer: 9.0 for Windows sub 270" (maybe AOL 9.0?) Even if this turns out to be a problem with other mailers, we might want to fix our MIME code (if possible) to handle it.
Summary: "This body part will be downloaded on demand" → [MIME] "This body part will be downloaded on demand"
I can't reproduce trying to construct a message myself. Ramin, can you please forward a defective message to our email addresses? You might also want to try a newer build. You have tested with Mozilla 1.3 beta. Could you please try with 1.3.1 or 1.4?
I'm also not able to duplicate my old results with 1.4RC3; moreover, I haven't seen any messages that misbehave this way since at least 1.4beta. At least some of the old examples (although not all) were virus payloads where I'm guessing the virus author got the MIME headers wrong. But the current code does not seem to be sensitive to quoting the 'boundary=' portion of the mail header. I tried recreating a bad header according the old recipe, and recent builds still extract the MIME fields just fine. If any of the QA people are still seeing this, I recommend that they look at the source of the message, and see if there is any quoting of MIME-related portions of the headers. If they do, then they are looking at a variant of the bug I saw; if they don't, you may be looking at something new.
This issue seems to be with the message structure and not the boundary header. It can be reproduced with using only Mozilla 1.4 client. The problem seems to be with the multipart/alternative bodypart. For example, if the message has a content type of multipart/mixed and the first body part is of multipart/alternative (with text/plain and text/html) and the second body part is just a binary attachment (for example, application/zip), then the mail client is not able to show the text of the message and shows instead "This body part will be downloaded on demand." Steps to reproduce: a) Configure your mail client to compose messages in html format b) Configure your mail client to send messages in both plain and html formats c) Send a message to yourself that contains html text (e.g. change the background color) with a zip attachment that's over 50K.
I'm using Mozilla 1.5b and IMAP, and I still get this bug. This differs from Rob Thorne's report in Comment #7. If I change "view | message body as" to Plain Text, then the message body appears. If I change it back to Original HTML or Simple HTML, then it goes back to "This body part will be loaded on demand." (This differs from Chris Sims's report in Comment #2.) I could not reproduce the bug using Henry Avetisyan's directions in Comment #8.
I am experiencing the exact same behavior describe in comment #9. However, this is on Thunderbird 0.3. It seems to only affect messages coming from Outlook or Outlook Express that have attachements.
For what it's worth, I'm seeing this same problem on Thunderbird 0.4a (031110 build), on a message that was sent from Eudora 5.2.1. It too has a quoted boundary= string. I see it only when viewing message as HTML (simple or original); the message appears normally when viewed as plain text.
Related to, or the same as bug 45790?
can I get an imap protocol log of a session where this imap message is selected, by following these instructions? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap Or, better yet, can anyone get me access to a test account with a mail message that shows this problem? Also, can you try this with tomorrow's build? I fixed a problem that occurred in the parsing of body structure responses when the quoted literals contained escape characters - that's almost certainly not the issue here, but it's worth a try.
Here is a message that causes this to occur. The behavior is the same as described in comment #9.
I put the attached message on three different imap servers and didn't have any problem reading it on any of them...I tried this with my tip debug mozilla build, a recent debug thunderbird build, and a 1.6a mozilla release build. It looks to me like the message source was the same on the imap server as the attached message. Can I get an imap protocol log of a session selecting this message? thx.
Here is the log of a session selecting the message and it not showing. I discovered an interesting thing however: if the message is in the Inbox imap folder, it appears normally and this bug doesn't apply. If the message is in any folder other than Inbox, this bug applies.
can you attach a log of trying this in the inbox so I can see the difference? From the log, it looks like we're only fetching the plain text part, which is surprising, unless it's just that we pick the first part - you do have it set to display html, right?
Imap log from thunderbird. Complete message comming up.
in my testing, Mozilla downloads the whole message, and not just a single part. Will debug further.
Here is the log when viewing the same message in the Inbox where the bug doesn't occur. And yes, it is set to view HTML.
I see how to reproduce this - you must have "show attachments inline" turned off. If I turn that off, then I can reproduce this.
we're not fetching the message in that last log, which leads me to think that you have your inbox configured for offline use, which removes the imap body structure handling from the picture.
so the quick workaround is to pick the view | display attachments inline menu item. I'll try to figure out how to fix the code to display the correct part.
4.x also just fetches the first part in this situation. I think the same protocol gets run in 4.x and Mozilla, so the problem is either in mime, or in the cache code - we're streaming the part into mime, but it still has the "this part will be downloaded..." content.
My imap account is not configured for offline use. When I enable 'show attachments inline' the complete message is displayed. Display message as is configured for 'simple html'. When set to 'plain text' I can see the plain text part of the message.
The problem was that we were chosing to fetch the first imap part in case of multi-part alternative messages, and left the other parts as "load on demand". But, the mime code picks the last part in multi-part alternative messages (as it's supposed to). this patch fixes the problem by making imap mpod load the last text part, not the first one - since that's what mime is going to display, that works a lot better. The one glitch is that is you chose viewing the message body as plain text, you'll get this bug again. Not quite sure how I'll fix that.
this fixes the aforementioned problem when the user is displaying messages as plain text with view attachments inline off
Attachment #137541 - Attachment is obsolete: true
Attachment #137576 - Flags: superreview?(mscott) → superreview+
checked into the M4 branch of tbird
fix checked into trunk. I think this should go into 1.6 as well.
really marking fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 137576 [details] [diff] [review] proposed fix I'm guessing you meant to request approval, although it may be too late.
d'oh, yeah. It's not crucial. We've lived with this bug for a long time now.
Comment on attachment 137576 [details] [diff] [review] proposed fix Removing obsolete review requests.
Comment on attachment 137576 [details] [diff] [review] proposed fix this fix has been on the trunk and in thunderbird for a while with no reports of problems. The code change only affects the previously broken case.
Attachment #137576 - Flags: approval1.4.2?
Comment on attachment 137576 [details] [diff] [review] proposed fix a=mkaply Please get in fast and mark "fixed1.4.2" Is the spacing off on this patch?
Attachment #137576 - Flags: approval1.4.2? → approval1.4.2+
yes, this is a -uw diff, so it doesn't show the whitespace cleanup I did with the initial trunk checkin.
*** Bug 45790 has been marked as a duplicate of this bug. ***
(In reply to comment #38) > *** Bug 45790 has been marked as a duplicate of this bug. *** (In reply to comment #37) > yes, this is a -uw diff, so it doesn't show the whitespace cleanup I did with > the initial trunk checkin. What version of Mozilla will include the fix to this bug? I'm using 1.6.20040.11308 -- downloaded 1/28 -- and it still happens. -- Bill Bache email@example.com Cell ph.: 503-358-5556 Home fax: 503-639-7674
Bill - the build you have is a 1.6 branch build. Seeing as 1.6 is out, what you have is the 1.6 release code with a new build date on it (i.e. there's no point in getting newer 1.6 builds any more) This fix didn't make it in time for 1.6. To get a build with the fix you'll need a trunk nightly build (i.e. a pre-1.7alpha build) from http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/
We are observing this with 1.7 so it is not fixed yet Server software: courier-imap 0.42.2-10 rebuilt for debian stable Client software: mozilla 1.7 on Windows XP Mail triggering the problem is a 125669 message containing 3 pdfs and an html part. The headers look OK and render correctly in kmail (from kde 3.2), outlook and evolution (1.4). Trying to change view as does not change a thing. Trying to change the headers on the server does not change anything either. Message headers look ok except the boundary line which is a bit strange. It is: boundary="=====================_113006344==_"
Bug 246415 has been opened about the persistence of this problem into 1.7.
You need to log in before you can comment on or make changes to this bug.