Open Bug 552806 Opened 14 years ago Updated 2 years ago

body part on demand problem- text/html before text/plain in multipart/alternative

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Type:
defect

Tracking

(Not tracked)

People

(Reporter: philbaseless-firefox, Assigned: philbaseless-firefox)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

Disk Cache file content(_CACHE_003_), after Clear Cache, view the mail
16.17 KB, text/plain
Details
35KB test mail, multipart/mixed ( multipart/alternative(single line text/html+single line text/plain), 6*image/gif, 1*text/plain )
34.67 KB, text/plain
Details
NSPR log(imap:5) for fetch from Gmail IMAP folder of "offline use=off"
22.42 KB, text/plain
Details
_CACHE_002_ content, after clear cache, fetch
6.40 KB, text/plain
Details
el problemo message
530 bytes, text/plain
Details
log of problemo
6.31 KB, text/plain
Details 
Didn't put up a sample but this is pretty simple

multipart/alternative

text/html

text/plain

with display attachments inline off and view body as original html we get the problem of 'this body part will be downloaded on demand'

The log shows it is fetching so not sure why. Maybe a mime display problem but it occurs on imap not local folders.

reverse the order and everything is ok.
Date: Tue, 16 Mar 2010 15:05:40 -0500 (CDT)
From: testing@invalid.invalid
To: testing@invalid.invalid
Subject: utf8 taken out content trans encoding
MIME-Version: 1.0
Content-Type: multipart/alternative;
  boundary="----=_Part_1348270_452951437.1268769938924"

------=_Part_1348270_452951437.1268769938924
Content-Type: text/html;


  <html>
testing html text
  </html>


------=_Part_1348270_452951437.1268769938924
Content-Type: text/plain;


          test plain text body
          reverse this part with above part and
          it is ok


------=_Part_1348270_452951437.1268769938924--
> multipart/alternative
> text/html
> text/plain

Unable to reproduce problem, with mail of above structure, with Tb 3.0.3 and Tb 3.2a1pre. I could see next (a) only.
  (a) Not tolerant with reversed preference order.
      Last text/plain part is displayed always. 
      Outlook frequently sent mail of this structure.
Next structure was needed to see 'this body part will be downloaded on demand', using Gmail IMAP folder of "offline use=off".
> multipart/mixed
>   multipart/alternative
>     text/html
>     text/plain
>   image/jpeg

Note:
image/jpeg part was not displayed in inline with Display Attachments Inline=On, even though next simplest header is used for the image/jpeg part. 
> --part-boundary
> Content-type: image/jpeg
> Content-transfer-encoding: base64
Does it make a difference if you switch off both memory and disk caches with browser.cache.{memory,disk}.enable, xor disable downloading MIME parts on demand with mail.server.default.mime_parts_on_demand = false?

If yes, maybe another manifestation of what I've observed in bug 529210 (end of downloading a MIME part on demand not correctly recognized when cached).
image/jpeg => image/gif(4KB), to make test case small.

Disk Cache file content(_CACHE_003_), after Clear Cache, view the mail.
  - Networking code fetches both text/html part and text/plain part,
    but writes text/html part data only in cache?
  - Mail display code shows text/plain part, which is most preferable part.
If small text/html part(single <br>... line only) and small text/plain part(single line only), all data for both text/html part and text/plain part was held in a cache file, and problem was not observed.

>(snip)
> --------------040302060904060309050900
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> <br>This is text/html part
>(snip, 388 "<br>This is text/html part" lines)
> <br>This is text/html part
> </body>
> </html>
> --------------040302060904060309050900
> X-Mozilla-IMAP-Part: 1.2
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> This body part will be downloaded on demand.
> --------------040302060904060309050900--
> --part-boundary
> X-Mozilla-IMAP-Part: 2
> Content-type: image/jpeg
> Content-transfer-encoding: base64
>
> This body part will be downloaded on demand.
--part-boundary--
(In reply to comment #3)
> Does it make a difference if you switch off both memory and disk caches with
> browser.cache.{memory,disk}.enable, xor disable downloading MIME parts on
> demand with mail.server.default.mime_parts_on_demand = false?

Mail size=34KB:   400 * "<br>This is text/html part"
                + 400 * "This is text/plain part"
                + 4063 bytes gif (roughly 5-6KB based64 encoded data)
Checked with trunk nightly build, Tb3.2a1pre.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100316 Shredder/3.2a1pre
Following settings. All of them are default of Tb. Nothing is changed.
> browser.cache.disk.capacity;51200
> browser.cache.disk.enable;true
> browser.cache.memory.capacity;4096
> browser.cache.memory.enable;true
> mail.imap.mime_parts_on_demand;true
> mail.imap.mime_parts_on_demand_max_depth;15
> mail.imap.mime_parts_on_demand_threshold;30000
> mail.server.default.mime_parts_on_demand;true
Correction. Sorry for spam.
  Mail size=34KB:   400 * "<br>This is text/html part"
                  + 400 * "This is text/plain part"
      + jpeg of larger than 4KB, but not so big, was used in the test.
Larger text/html part is required to see problem with text/html part and text/plain part only? Or multipart/related part(text/html and image/xxx in it) is required for HTML mail part in multipart/alternative?
Test mail structure:
> multipart/mixed
>   multipart/alternative
>     text/html
>     text/plain
>   6 * image/gif
>   1 * text/plain 
I was unable to reprodue problem with 28KB mail or smaller mails with same structure. So I increased number of image/gif part to six(34KB mail).

This structure is semantically "not well formed", like test mail for bug 516211 (the mail initially produced bug 501253). My case is probably not same as your original comment #0 case, but I think similar issue is involved.

View settings:
  View/Message Body As/Original HTML
  View/Display Attachments Inline=Off
fetch for text/html part only was requested.
> 14 UID fetch 1 (BODY.PEEK[1.1]) 	
> * 1 FETCH (UID 1 BODY[1.1] {259} 	
Message pane display : 
> This body part will be downloaded on demand. <= for mail body, text/plain part in multipart/alternative
> --------------------------------------------
>
> This body part will be downloaded on demand. <= for text/plain attachment part
Attachment pane display :
> Part 1.2   Part 1.3   Part 1.4   Part 1.5
> Part 1.6   Part 1.7   Part 1.8(text/plain attachment)
testing with following 'user set' prefs:
browser.cache.disk.capacity;0
mail.imap.mime_parts_on_demand_threshold;1
mail.inline_attachments;false
Related to bug 554305 you've filed today? Also, per comment #3, please try to reproduce with both disk *and* memory caches disabled.
Attached file el problemo message — 
this message shows for my TB with sync and caches off.
view as original html, download on demand
view as plain, ok.
log to follow
Attached file log of problemo — 
imap fetches headers and fetches html body and filling for plain

This is correct for imap fetching operation. Apparently we have a mime problem in outputting the data when it gets it?
Please confirm.
Problem was observed with simple multipart/related mail(HTML with <img>'s).
> Attachment 435098 [details] (a test case for bug 545126, bug 536873)
> Case-02 : multpart/related, 40 <img src="cid:....">, 89589 bytes(21*4096+3573)
> (save as .eml, drag the .eml file thread pane of a folder of Tb 3)
Whole mail data was downloaded to Disk Cache by "View Source" or change to "Display Attachment Inline=On", and problem was not observed until clear of Disk Cache.
If small mail of same structure(Case-01, 9KB, 4 <img>s), problem was not observed. (whole mail data is downloaded at first fetch)

It looks that there are slightly different two cases.
(a) multipart/alternative mail, reversed  part order.
      text/html,text/plain instead of valid order of text/plain,text/html
    due to inconsistency betwee netwoking and mail display.
(b) multipart/related HTML mail with embeded images.
    due to "download on demand".

(Mail data in Disk Cache)
>(snip)
> Content-Type: multipart/related; boundary="boundary"
> MIME-Version: 1.0
> 
> --boundary
> X-Mozilla-IMAP-Part: 1
> Content-Type: text/html; charset="ISO-8859-1"
> 
> This body part will be downloaded on demand.
> --boundary
> X-Mozilla-IMAP-Part: 2
> Content-Type: image/jpeg
> Content-Transfer-Encoding: base64
> Content-ID: <firebird-01>
> 
> This body part will be downloaded on demand.
>(39 image/jpeg parts follow)
Assignee: nobody → philbaseless-firefox
http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimemalt.cpp#155

David, do you understand this comment. It seems to be what I keep running into when tracing this bug...so far.

when pref is for original html
email is 
mp/alt
--text/html    Imap downloads body
--text/plain   IMAP fills body with 'download on demand' message

mimemalt retrieves both and the display is the last one text/plain just like the comment says.
Phil, not sure what you're asking. Multipart alternative defines the parts as in order of increasing faithfulness to the original content, so text/html should be *after* text/plain, and we pick the last part we know how to display. So that code is throwing away the previous part because it knows how to display the newer, richer part.
(In reply to comment #16)
> , so text/html
> should be *after* text/plain,

but if the message is not what do we need to do. If you say we need to display the last part then I should change the IMAP code to download all text parts of mp/alt. Otherwise I imagine we need to create a mp/alt child to suit our prefs setting only.
Blocks: 568574
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: