505172 - (multipartfailtracker) [Meta] Bad handling, or different handling from user's preconception, of mail of multipart/alternative in multipart/related or vice versa (semantically incorrect structure for ordinal/traditional mailer, or mis-use of mixed, related, alternative)

Status: NEW

(MailNews Core :: MIME, defect)

Description

[WADA:World Anti-bad-Duping Agency]

As seen in Bug 504728, many major problems with "multipart/alternative in multipart/related" (semantically incorrect structure) seems to be already resolved. This bug is to close many old bugs relate to "multipart/alternative in multipart/related".

(Quick observation of current behaviour of Tb 2 in Bug 504728)

> (A. Typical mail structure)
>
>  multipart/related
>  part-1 : multipart/alternative (<=mail_body of multipart/related) 
>           part-1-1 : text/plain
>           part-1-2 : text/html
>  part-2 : image/jpeg (<=content pointed by <img cid="...">) 
>  part-3 : image/jpeg (<=content pointed by <img cid="...">)
>
> (B. Displayed result by Tb's current quirks is similar to next mail structure)
>
>  (When View Message Body As = Original HTML / Simple HTML)
>  multipart/related
>  part-2-1X: text/html  (<=chosen mail_body)
>  part-2-2X: image/jpeg (<=content pointed by  <img cid="...">) 
>  part-2-3X: image/jpeg (<=content pointed by  <img cid="...">)
>
> (When View Message Body As = Plain Text)
>  multipart/mixed
>  part-1X: multipart/alternative
>           part-1X-1 : text/plain (<=chosen mail_body)
>           part-1X-2 : text/html  (not used)
>  part-2X: image/jpeg 
>  part-3X: image/jpeg
>
> (C. A should be next semantically)
>
>  multipart/alternative
>  part-1 : text/plain
>  part-2 : multipart/related
>           part-2-1 : text/html
>           part-2-2 : image/jpeg (<=content pointed by <img cid="...">) 
>           part-2-3 : image/jpeg (<=content pointed by <img cid="...">)
>  Note: text/plain part is not used currently.
>        Text converted from text/html is used when Message Body As=Plain Text.

Comment 1

[Ben Bucksch (:BenB)]

> Text converted from text/html is used when Message Body As=Plain Text.

FYI, this is preffed: mailnews.display.prefer_plaintext
The reason is that we preserve links and some information, and many sender's converters do not.

B looks strange. "Original HTML", "Simple HTML" and "Plaintext" modes should all have the same output structure, just that body part different, as far as I know the code.

I don't know what this bug is about.

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #1)
> > Text converted from text/html is used when Message Body As=Plain Text.
> FYI, this is preffed: mailnews.display.prefer_plaintext
> The reason is that we preserve links and some information, and many sender's
> converters do not.
> B looks strange. "Original HTML", "Simple HTML" and "Plaintext" modes should
> all have the same output structure, just that body part different, as far as I
> know the code.

Please see Bug 482198. Have you execute duplication test of Bug 482198?
Have you execute duplication test of Bug 504728?
Can we change Tb's behaviour when "View/Message Body As=Plain Text" by setting change of mailnews.display.prefer_plaintext in Bug 482198's case?

> I don't know what this bug is about.

As I wrote in comment #0, this bug is simply temporary bug to close old bugs, based on observation of displayed result for "multipart/alternative in multipart/related" mail or message/rfc822 part in Bug 504728.

Comment 3

[WADA:World Anti-bad-Duping Agency]

Note:
Remaining big issue around multipart/alternative and/or multipart/related is Bug 394322 which is common issue of HTML mail(irrelevant to mail structure).  
> Bug 394322 forward inline from Simple HTML view creates blank email

Comment 4

[WADA:World Anti-bad-Duping Agency]

> B looks strange. "Original HTML", "Simple HTML" and "Plaintext" modes should
> all have the same output structure, just that body part different, as far as I
> know the code.

Structure in (B) is not real structure used by Tb. That is structure which produces same display result including attachment pane display by Tb.

Second purpose of of this bug is to know "current Tb's behaviour" and "what should be" when mail has nested alternative+related and nested related+alternative, in order to close old bugs as WORKSFORME/DUP/INVALID.

I think (A) and (C) should produce completely same result.
However, as seen Bug 482198, Tb looks to do next.

 (C) Semantically good structure. Tb generates this structure for HTML mail.
     multipart/alternative
     part-1 : text/plain
     part-2 : multipart/related
              part-2-1 : text/html
              part-2-2 : image/jpeg (<=content pointed by <img cid="...">) 
              part-2-3 : image/jpeg (<=content pointed by <img cid="...">)

(a) mail_body of part-2 = text/html.
(b) content of "part-1 of multipart/alternative" is equivalent to
    "part-2 of multipart/alternative", because multipart/alternative.
(c) part-1 of multipart/alternative is text/plain part.
So Tb converts to next. (ignore alternative and text/plain part)
   multipart/related
   part-1 : text/html
   part-2 : image/jpeg (<=content pointed by <img cid="...">) 
   part-3 : image/jpeg (<=content pointed by <img cid="...">)
Then display becomes "text converted from HTML" when Message Body As=Text Plain.

Quirks is rather done on (C)?

Comment 5

[WADA:World Anti-bad-Duping Agency]

I've found Bug 253830 (reported in 2004) for phenomenon of Comment #4.

Comment 6

[WADA:World Anti-bad-Duping Agency]

Oh, Ben Bucksch was comment poster of Bug 253830 Comment #3 and #12.
Ben Bucksch, why Tb's behavior is different between structure (A) and structure (C)?

Comment 7

[Ben Bucksch (:BenB)]

WADA, because of bug 478175 (now fixed thanks to asuth).

Comment 8

[Thomas D. (:thomas8)]

WADA, does alias "multipartfailtracker" roughly describe the scope this meta bug?
I want to add alias so that it will be more prominent (easier to see) on dependent bugs, which will make it easier to identify dupes.

Meta Bug 269826 seems to be different enough.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to Thomas D. from comment #8)

No. This bug is for problems relevant to multipart/related and/or multipart/alternative. "multipartfailtracker" has too wide scope.

Comment 10

[Jorg K (CEST = GMT+2)]

Anindya, hi, you've been looking at new bugs recently to help in bug triage.

You could help us to look at some really old bugs. If you have time, take a look at all the bugs listed above on which this bug here depends. Take a look at all of them and see whether you can reproduce them.

I've just looked at bug 2903 and closed it since it is clearly not a problem any more.

The aim is to close as many bugs as possible. Before you close a bug, please NI me so I can take a look. If a bug is still valid, please leave a comment describing your test. I've just picked bug 558128 at random and added bug 558128 comment #15.

Thanks in advance for your help.

Comment 11

[Jorg K (CEST = GMT+2)]

Actually, I've looked at the higher numbers, these ones I haven't looked at yet:
65159 101719 103743 108010 200412 230119 253830 279907 348045 348468

Comment 12

[Anindya-Pandey]

Sorry for the late reply. I'll start looking at the bugs.

Comment 13

[Jorg K (CEST = GMT+2)]

Late reply? Sometimes you wait for weeks if not months before people answer ;-(

Comment 14

[Jorg K (CEST = GMT+2)]

Anindya, hi again, maybe this was a bad idea. You need good knowledge of MIME structures in a message to understand these bugs. Anyway, I've looked at everything but these six:
65159 101719 103743 108010 200412 230119.