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

NEW

Status

9 years ago
9 years ago

People

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

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Assignee)

Description

9 years ago
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.
(Assignee)

Comment 1

9 years ago
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

Comment 3

9 years ago
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).
Created attachment 432988 [details]
Disk Cache file content(_CACHE_003_), after Clear Cache, view the mail

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?
Created attachment 433016 [details]
35KB test mail, multipart/mixed ( multipart/alternative(single line text/html+single line text/plain), 6*image/gif, 1*text/plain )
Created attachment 433017 [details]
NSPR log(imap:5) for fetch from Gmail IMAP folder of "offline use=off"
Created attachment 433023 [details]
_CACHE_002_ content, after clear cache, fetch

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)
(Assignee)

Comment 10

9 years ago
testing with following 'user set' prefs:
browser.cache.disk.capacity;0
mail.imap.mime_parts_on_demand_threshold;1
mail.inline_attachments;false

Comment 11

9 years ago
Related to bug 554305 you've filed today? Also, per comment #3, please try to reproduce with both disk *and* memory caches disabled.
(Assignee)

Comment 12

9 years ago
Created attachment 434516 [details]
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
(Assignee)

Comment 13

9 years ago
Created attachment 434517 [details]
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)

Updated

9 years ago
Assignee: nobody → philbaseless-firefox
(Assignee)

Comment 15

9 years ago
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.

Comment 16

9 years ago
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.
(Assignee)

Comment 17

9 years ago
(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.
(Assignee)

Updated

9 years ago
Blocks: 568574
You need to log in before you can comment on or make changes to this bug.