879197 - When both HTML and plain text content present, HTML may not be shown (multipart/alternative{text/html + text/plain}, placed in reversed order wrongly by sender)

Status: RESOLVED DUPLICATE of bug 574989

(Thunderbird :: Message Reader UI, enhancement)

Description

[Crend King]

Attachment: Contains Bad.eml, Good.eml and a screenshot when displaying Bad.eml

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130516190140

Steps to reproduce:

I received an email that is supposed to have HTML content, and I'm able to see the HTML content in other email clients. In Thunderbird it only shows the plain text content. I fresh installed Thunderbird in virtual machine and see the same problem.


Actual results:

I checked the message source. It turns out that the email contains both HTML and plain text content. The HTML appears first, splitted by a boundary, then plain text. So I constructed a simpler version (as in attachment, "Bad.eml") that demonstrate the problem. Even I choose "Message Body As" > Original HTML, it still shows "Plain text". However, if edit the file to make plain text appear first, then HTML ("Good.eml"), Thunderbird correctly shows both format.


Expected results:

When both formats present in the email, both formats should be able to display, no matter what order they appear in the email message source.

This bug may related to bug 447887.

Comment 1

[WADA:World Anti-bad-Duping Agency]

(In reply to Crend King from comment #0)
> Expected results:
> When both formats present in the email, both formats should be able to
> display, no matter what order they appear in the email message source.

Do you correctly understand definition of multipart/alternative by RFC?

Comment 2

[Crend King]

Thanks for reply. I read RFC 2046 and do see Thunderbird's logic. However I want to argue in both technical and non-technical aspects.

Technically, the RFC also written that "Either the user should be shown the last recognized version or should be given the choice." Since Thunderbird is a MIME-conformant viewer, and it does offer the choice of which format to display, it should display whatever user chooses, given it understands that format.

Non-technically, I think this is a issue of usability, not a issue of how standard-compliant Thunderbird is. Normal user is less likely to read a 43-page specification and praise Thunderbird doing the right thing, but more likely to simply switch to another client. If Firefox fails to render a web page because missing </html>, it would not be much success as today.

Frankly, the email I receive is from Dell.com about order status. Previously similar emails I received are in the "Good.eml" form. This time there may be some bug in their email server. But consider how many other Thunderbird users would have received emails from Dell in the same time window.

Android native email client, Zimbra Desktop and GMX.com web email interface are all able to display HTML correctly.

Comment 3

[WADA:World Anti-bad-Duping Agency]

If you collectly uderstand RFC 2046 well, why bug was not opened with Severity!=Enhancement?

If HTML part doesn't have many embed images(not so many <img> tag is used for important data in multipart/related), View/Message Body As/All Body Parts is already available for such mail, which can be called malformed, which was generated by casual programmer of mail application who never respects RFC.
All Body Parts menu is shown by following prefs.
  mailnews.display.show_all_body_parts_menu = true
This mode treats any multipart/xxx as multipart/mixed, so any subpart of any nest level is shown as a part of multipart/mixed.

As for Tb's behavior on multipart/alternative, improvement like next is possible, and is already requesed in other bug, although it's not officially accepted as required enhancement by developers yet.
  View/Message Body As/Plain Text :
    Use text/plain part, as mailer who can understand text/plain,
    according to priority of part requested by mail sender.
  View/Message Body As/Original HTML or Simple HTML :
    Use text/html part, as mailer who can understand text/html,
    and as mailer who doesn't love text/plain deeply,
    according to Tb user's request of Originl/Simple HTML mode.
  In any mode, show non-diplayable part, such as audio/wav, as
  "attachment", because mail sender may want playing voice mail
  and it may be highest priority for sender but Tb doesn't have
  capability to process voice mail.
These are never RFC violation. Mailer can choose any part under multipart/alterative and can show any part in inline or as attachment, because it's never prohibited by RFC 2046 :-)

Comment 4

[WADA:World Anti-bad-Duping Agency]

Sorry, typo.
  Why bug was not opened with Severity==Enhancement?

Comment 5

[Crend King]

Sorry. I think this is the first time I report bug to Tb. I just left all options I do not fully understand as default. If necessary, I can change it to Enhancement.

View body all parts shows the missing HTML for that email. I would appreciate if Tb respect user's choice. It would be a great enhancement if

* user chooses View/Message Body As/Original HTML or Simple HTML, and
* the email contains text/html part.

As for standard-compliant, I personally think Tb should do this in the first place:

Provide 4 options in View/Message Body As: Auto, Original HTML, Simple HTML and Plain Text. For Auto, it strictly follow the RFC to display the last part. For the other 3 options, as suggested above, always display which user chooses and ignore the ordering.

BTW, what is the bug number you mentioned as "is already requesed in other bug"? Thank you!

Comment 6

[WADA:World Anti-bad-Duping Agency]

One or a few bugs listed in dependency tree for meta bug 505172, but I don't remeber bug number.

Comment 7

[WADA:World Anti-bad-Duping Agency]

As for (a) "reversed order of text/plain and text/html in multipart/alternative" case, your case, following quirk is sufficient.
  If View/Message Body As/Plain Text, behaves as 
      mailer who knows text/plain only, doesn't know text/html.
  If View/Message Body As/HTML, behaves as
     mailer who knows text/html only, doesn't know text/plain.
  Show unknown mime-part as attachment.
However, the mail is malformed mail, so other problems may exist in mail in many cases.
(b) Even though multipart/alternative, text/plain part only or
    text/html part only.
(c) Even though multipart/alternative, data in text/plain part is null
    or space only, or data in text/plain part is null or space only.
(d) Even though multipart/alternative, content in text/plain part
    and content in text/html part is absolutely different.
These are actual mail sent to Tb by casual mail application programmers who perhaps never reads mail related RFC or manual.
And, in case of (d), users usually(almost surely) request Tb developer to display *CORRECT* part for him. What can developers do?

Further, following is permitted in multipart/alternative(one of major objectives of multipart/alternative).
(e) multiple versions of data. mail recipient side mailer can select
    part according to physical display size and capability.
  image/jpeg   #1  300 x  200 in monochrome, same image/jpeg in color
  image/jpeg   #2  600 x  400 in monochrome, same image/jpeg in color
                |
  image/jpeg #998 3000 x 2000 in monochrome, same image/jpeg in color
  image/jpeg #999 6000 x 4000 in monochrome, same image/jpeg in color
So, "multiple text/plain parts and multiple text/html parts in multipart/alternative" is absolutely correct syntactically, and is never wrong semantically.
(f) multiple text/plain parts and multiple text/html parts
    text/plain #1 : short version
    text/plain #2 : long  version
    text/html  #1 : short version
    text/html  #2 : long  version
In this case of (f), user's request to developer is "display *CORRECT* part for him" too. If (a) "wrong order" and (b) to (d) are mixed, what can developers do? :-)

"malformed mail" is not multipart/alternative only phenomenon. Casual Web application programmers generate malformed multipart/related and malformd multipart/mixed too.
If quirks for malformed multipart mail will be implemented, we should consider all cases, instead of quirk for "wrong order in multipart/alternative" case only. 

View/Message Body As/All Body Parts is answer from developers and is an generic and multi-purpose solution provided by Tb developers for "malformed multipart".

Another concern.
If following quirk is introduced,
  Display non-used part as attachment for case like (e)
if such quirk is applied blindly, displayed result will be perhaps chaos.
As you say, I also think such quirks should be optional, and mode like "Auto" you call or "Standard mode" like one will be needed.

Comment 8

[WADA:World Anti-bad-Duping Agency]

Bug 574989 was for same (a) "reversed order of text/plain and text/html in multipart/alternative". In that bug, I wrote an idea of quirks for malformed multipart/alternative and malformed multipart/related. An idea of quirks for "mis-use of cid: URL of <img> of HTML mail and Content-ID: in multipart/mixed instead of correct multipart/related" is written in other bug.

Comment 9

[Crend King]

Thanks WADA. I think this bug is duplicate with bug 574989 and bug 691120.

In terms of "If quirks for malformed multipart mail will be implemented, we should consider all cases, instead of quirk for "wrong order in multipart/alternative" case only." I agree. I wonder if there is any progress of development on this topic, of still in discussion phase.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to Crend King from comment #9)
> I think this bug is duplicate with bug 574989 and bug 691120.

Even though report of same phenomenon on same mail structure, and even though idea of quirks for malformed multipart is written in bug(s), I don't know bug for explicit request of "quirks for malformed multipart"(surely Enhancement).

> I wonder if there is any progress of development on this topic, of still in discussion phase.

You are correct.
You may be better to open separate bug for explicit enhancement request, after summarizing required features in this bug and some other bugs.

Comment 11

[Jorg K (CEST = GMT+2)]

I see no reason not dupe this to 574989.