Open Bug 505172 (multipartfailtracker) Opened 11 years ago Updated 3 years ago

[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)

Categories

(MailNews Core :: MIME, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: World, Assigned: World)

References

(Depends on 8 open bugs)

Details

(Keywords: meta)

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.
> 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.
(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.
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
> 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)?
Depends on: 253830
I've found Bug 253830 (reported in 2004) for phenomenon of Comment #4.
No longer depends on: 253830
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)?
Depends on: 253830
Depends on: 530111
No longer depends on: 530111
Depends on: 246415, 516211
Depends on: 244741
Summary: [Meta] Bad handling of mail of multipart/alternative in multipart/related(semantically incorrect structure) or vice versa → [Meta] Bad handling of mail of multipart/alternative in multipart/related or vice versa (semantically incorrect structure for ordinal/traditional mailer)
Depends on: 540185
WADA, because of bug 478175 (now fixed thanks to asuth).
Depends on: 558128
Depends on: 560210
Depends on: 566120
Depends on: 549883
Depends on: 560877
Component: General → Backend
Product: Thunderbird → MailNews Core
QA Contact: general → backend
Component: Backend → MIME
QA Contact: backend → mime
Depends on: 592819
Depends on: 597821
Depends on: 610669, 624555
Depends on: 632961
Depends on: 636253
Depends on: 640983
Depends on: 659242
Depends on: 667019
Depends on: 668259
Depends on: 669309
Depends on: 670884
Depends on: 682226
Depends on: 674473
Depends on: 694337
No longer depends on: 694337
Depends on: 697702
Depends on: 702569
No longer depends on: 702569
Depends on: 712885
Depends on: 716983
Depends on: 743950
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.
Alias: multipartfailtracker
(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.
Depends on: 760412
No longer depends on: 670884
No longer depends on: 716983
Depends on: 559852
Depends on: 879197
Summary: [Meta] Bad handling of mail of multipart/alternative in multipart/related or vice versa (semantically incorrect structure for ordinal/traditional mailer) → [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)
Depends on: 2903
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.
Flags: needinfo?(anindyapandey)
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
Sorry for the late reply. I'll start looking at the bugs.
Flags: needinfo?(anindyapandey)
Late reply? Sometimes you wait for weeks if not months before people answer ;-(
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.
Depends on: 1367973, 1362539
You need to log in before you can comment on or make changes to this bug.