659242 - text and HTML multipart/alternative display does not work if HTML has inline related image

Status: RESOLVED DUPLICATE of bug 253830

(MailNews Core :: MIME, defect)

Description

[a507]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10

Trying to view a message with a text alternative fails if the HTML alternative is of type multipart/related and contains an inline image part.

This structure does not allow me to see the text alternative:
MSG: Content-type: multipart/alternative
  ALT1: Content-type: text/plain
  ALT2: Content-type: multipart/related
     HTML: Content-type text/html
     IMG: Content-type image/gif
     
However, this structure does let me view both alternatives:

MSG: Content-type: multipart/alternative
  ALT1: Content-type: text/plain
  ALT2: Content-type: text/html


In the failing case, selecting "message body as->plain text" simply causes TB to display the HTML version without formatting--and shows the inline image as an attachment with a name 1.1.2. If I reverse the alternatives in the message, I can only view the text alternative. Seems that whichever is last is the one that can display.



Reproducible: Always

Steps to Reproduce:
1. structure a message as described above (e.g. using java mail API) and send to self
2. view in Thunderbird from IMAP account


Actual Results:  
As described above, one of the alternatives does not display. In the attached test messages, the text and HTML alternatives have slightly different text to show that one or the other cannot be displayed.

Expected Results:  
When alternatives of suitable MIME type are available, switching between plain text and HTML message views should each use the available alternative.

Additionally, if an inline image is included in a multipart/related part alongside the HTML, it should not be displayed as an attachment when viewing the message as text.

Can also reproduce this directly in TB by creating a new message with an inline image inserted and sending to self using the "format->plain and rich (html) text" message option.

Comment 1

[a507]

Attachment: non-working case

Comment 2

[a507]

Attachment: working case

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to a507 from comment #0)
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
> MSG: Content-type: multipart/alternative
>   ALT1: Content-type: text/plain
>   ALT2: Content-type: multipart/related
>      HTML: Content-type text/html
>      IMG: Content-type image/gif

> Expected Results:  
> When alternatives of suitable MIME type are available, switching between
> plain text and HTML message views should each use the available alternative.

This part is dup of bug 253830.

> Additionally, if an inline image is included in a multipart/related part
> alongside the HTML, it should not be displayed as an attachment when viewing
> the message as text.

AFAIK, your this request is already fulfilled by Tb 5/6(by fix of bug 351224). Can you see this part with newest Tb release?

Both are already known phenomenon and are reported in many bugs. Confirming before duping.

Comment 5

[Alain Knaff]

(In reply to a507 from comment #0)
> Additionally, if an inline image is included in a multipart/related part
> alongside the HTML, it should not be displayed as an attachment when viewing
> the message as text.

There should still be some way to view the image though.

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to Alain Knaff from comment #5)
> There should still be some way to view the image though.

To Alain Knaff, who is not origial bug opener of this bug:
Are you requesting more than already-implemented-enhancement of bug 602718(for correctly referred images in multipart/related, with View/Message Body As/Plain Text) and already-requested-enhancement of bug 674473(for parts incorrectly placed in multipart/related by mail sender)?
(I believe that these two bugs can very easily be reached by searching B.M.O for "multipart/related" in bug summary.)

Comment 7

[Alain Knaff]

No, my comment was more intended as a pre-emptive caution about not introducing new issues (accessibility of attachments) while fixing the main issue (correct display of mail body).

And I did recently stumble across such an attachment accessibility issue in 692040 which still was not fixed as recently as 2 days ago.