565949 - Plain-text reply quotes HTML part of a multipart/alternative message

Status: NEW

(MailNews Core :: Composition, defect)

Description

[palswim]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

When I reply to a multi-part message in plain text, Thunderbird seems to parse and create a text rendition of the HTML part of the message instead of using the plain text part to quote the message to which I reply.  This leads to unintelligible formatting, especially after a thread of replies back and forth.

Reproducible: Always

Steps to Reproduce:
1. Have a friend send you a multipart HTML/text e-mail with the text: "My e-mail address: [e-mail]"
2. Compose a reply in plain text to that message
3. Look at the quoted text from the original message
Additional steps:
4. Send a plain-text reply to your friend, with the full quote of the original message.
5. Have your friend again send a reply to you (quoting the whole message) with a multipart HTML/text e-mail.
6. Compose a reply in plain text to this new message.
7. Look at the quoted text from the messages, especially the first message.
Actual Results:  
Composing your first reply, you see "My e-mail address: [e-mail]" has changed to:
> My e-mail address: [e-mail] <mailto:[e-mail]>

After your reply and your friend's reply, composing a reply, you see this has changed to:
>> My e-mail address: [e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail]>

Expected Results:  
Composing your first reply, "My e-mail address: [e-mail]" should look like:
> My e-mail address: [e-mail]

After your reply and your friend's reply, composing a reply, you should see this has changed to:
>> My e-mail address: [e-mail]

Gmail, by default, sends mutlipart HTML/text messages.  This problem is even worse when you're quoting a reply to a message.

On Mon, May 10, 2010, John Doe <[e-mail]> wrote:

becomes

> On Mon, May 10, 2010, John Doe <[e-mail] 
> <mailto:[e-mail]>> wrote:

Comment 1

[rsx11m]

With current Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.5pre) Gecko/20100515 Lanikai/3.1pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100513 SeaMonkey/2.1a2pre builds I'm getting the quote identical to what is displayed. I'll attach a test case containing different plain-text and HTML parts.

Replying from Original or Simple HTML display results in down-conversion to plain text from the HTML part to plain-text composition. Conversely, displaying in plain text up-converts the plain-text part to HTML if this is the composition mode. The down-conversion from HTML to plain-text representation causes the issues described. The workaround would be to leave View > Message Body As on Plain Text, which won't help though if the message only has a text/html but no text/plain part.

It appears to me that the format is handled intuitively correctly, though it may be easier to just pick the plain-text MIME part for the quote if it's there (which may only cause issues if the contents of the parts are different). The other issue is related to the serializer for down-converting HTML to plain text, I'd think there may be bugs pending for this already.

Comment 2

[rsx11m]

Attachment: Minimal test case

Shows "This is the plain-text part..." in View > Message Body As > Plain Text;
or "This is the HTML part..." in View > Message Body As > Original/Simple HTML.

Comment 3

[rsx11m]

Related to the expansion of URLs during down-conversion: bug 135239.
Also see discussion in bug 297497.

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #1)
> (which may only cause issues if the contents of the parts are different).

As multipart/alternative mail, mail receiver can always use text/plain part as "text converted from text/html part by mail sender" based on RFC's definition of multipart/alternative.
As RFC never prohibits different contents in different parts of multipart/alternative, mail sender can send different contents in different parts. However, I believe next phenomenon is mail sender's fault,
  - Different content is displayed by View/Message Body As/Plain Text
    and View/Message Body As/Original HTML.
  It's reported as bug of "if null/space-only text/plain, nothing is shown."
and I think next is better to be avoided.
  - Different content is NOT displayed by View/Message Body As/Plain Text
    and View/Message Body As/Original HTML.
  Tb displays converted text from html by View/Plain Text when some kinds of
  mail structure of nested multipart/xxx, even though text/plain part exixts.
In any of View and Composition, Tb's behaviour is better to be next and consistent, although null content part case should be cared for.
  - Use text/plain part always when mail data is used as "Simple Text",
    if text/plain part exists in multipart/alternative.
  - Use text/html part always when mail data is used as "HTML",
    if text/html part exists in multipart/alternative.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Note:
Bug 297497 Comment #1 on 2005-06-15 is for opposite opinion.
> I would expect the quoted text to be the text I was viewing.
> If I'm viewing the message as Original HTML, that's the message body I expect to see.
He worried about confusion when different contents in different parts of multipart/alternative.
I worried about problem like this bug even when same content in both text/html part and text/plain part of multipart/alternative as RFC defines.

Comment 6

[rsx11m]

Since the original bug 297497 was closed, and there seems to be enough substance (but also concerns) to warrant considering this as an RFE, thus confirming as such. Adding a serializer option to omit <URL> coding is
covered already in bug 135239 and should equally apply to mail conversions.

Comment 7

[rsx11m]

> My e-mail address: [e-mail] <mailto:[e-mail]>

BTW: The code snippet I've looked up in bug 135239 comment #43 also explains why the mail address is expanded in this way . The comparison checks if the string is literally identical to the link, thus doing the following:

  if ("[e-mail]" != "mailto:[e-mail]") add URL;

It may be a separate bug, but also checking if the protocol part is omitted in the text version would help resolving such redundancies. Another example are web links, e.g. "www.example.com" instead of "http://www.example.com".