Open
Bug 505172
(multipartfailtracker)
Opened 15 years ago
Updated 1 year 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)
MailNews Core
MIME
Tracking
(Not tracked)
NEW
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.
Comment 1•15 years ago
|
||
> 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.
Assignee | ||
Comment 2•15 years ago
|
||
(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.
Assignee | ||
Comment 3•15 years ago
|
||
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
Assignee | ||
Comment 4•15 years ago
|
||
> 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)?
Assignee | ||
Comment 5•15 years ago
|
||
I've found Bug 253830 (reported in 2004) for phenomenon of Comment #4.
No longer depends on: 253830
Assignee | ||
Comment 6•15 years ago
|
||
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)?
Assignee | ||
Updated•15 years ago
|
Assignee | ||
Updated•15 years ago
|
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)
Comment 7•15 years ago
|
||
WADA, because of bug 478175 (now fixed thanks to asuth).
Assignee | ||
Updated•14 years ago
|
Component: General → Backend
Product: Thunderbird → MailNews Core
Updated•14 years ago
|
QA Contact: general → backend
Assignee | ||
Updated•14 years ago
|
Component: Backend → MIME
QA Contact: backend → mime
Assignee | ||
Updated•14 years ago
|
Comment 8•13 years ago
|
||
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
Assignee | ||
Comment 9•13 years ago
|
||
(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.
Assignee | ||
Updated•11 years ago
|
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)
Comment 10•8 years ago
|
||
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)
Comment 11•8 years ago
|
||
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•8 years ago
|
||
Sorry for the late reply. I'll start looking at the bugs.
Flags: needinfo?(anindyapandey)
Comment 13•8 years ago
|
||
Late reply? Sometimes you wait for weeks if not months before people answer ;-(
Comment 14•8 years ago
|
||
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.
Updated•7 years ago
|
Updated•2 years ago
|
Severity: normal → S3
Updated•1 year ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•