777356 - Correctly referenced inline images <img src="cid:..."> should be displayed for cases of multipart/mixed instead of multipart/related

Status: RESOLVED DUPLICATE of bug 61815

(Thunderbird :: Message Reader UI, enhancement)

Description

[Eric]

Attachment: Testcase1.doc: source of sample message + screen shots showing the viewing pane (see individual attachments below)

inline images do not display in the body of the email but instead appear at the bottom of the email as separate parts.  It's as if  TB is not recognizing the multipart/mixed content type correctly.

Comment 1

[Thomas D. (:thomas8)]

Attachment: Testcase1.eml

Per comment 0, this message shows the bug (extracted from reporter's attachment 645765 [details])

Comment 2

[Thomas D. (:thomas8)]

Comment on attachment 646023 [details]
Testcase1.eml

(In reply to Thomas D. from comment #1)
> Created attachment 646023 [details]

Sorry, attachment 646023 [details] doesn't belong here.

Comment 3

[Thomas D. (:thomas8)]

Attachment: Testcase1.eml

Per comment 0, this message shows the bug (extracted from reporter's attachment 645765 [details], correct attachment this time)

Eric, thanks for providing testcase & screenshots. Pls avoid bundling testcase message and screenshots in a proprietary word document. It makes your testcase a lot harder to access and analyse.

Comment 4

[Thomas D. (:thomas8)]

Attachment: Screenshot1: First half of Testcase1.eml in message reader (with broken inline img)

(extracted from attachment 645765 [details])

Comment 5

[Thomas D. (:thomas8)]

Attachment: Screenshot2: Second half of Testcase1.eml in message reader (with supposed inline img as file attachment)

(extracted from attachment 645765 [details])

Comment 6

[Thomas D. (:thomas8)]

Reporter's comment on testcase.eml of attachment 646026 [details], and screenshots of attachment 646027 [details] & attachment 646028 [details] (extracted from attachment 645765 [details]):

> Images should be displayed in the main body part … the coBrandLogo.gif should be
> where the square broken image is, but instead as seen in the next screen capture
> on the next page, it is displayed as a third part at the bottom of the email
> instead.  This never used to happen and I can’t remember exactly which update
> caused it to break.

Comment 7

[Jim Porter (:squib)]

Do you have "Show All Body Parts" enabled? That's the only way a recent version of Thunderbird should show attachments like "Part 1.1", and it will exhibit the problem described in comment 0. You should turn that off, since it's mostly for debugging and dealing with strange and broken messages.

Comment 8

[Thomas D. (:thomas8)]

Attachment: Testcase-1b.eml: Testcase1 with better indication & annotation of missing images

This is not a bug (but imo a valid RFE):

Images are not shown inline because HTML part and images are inside multipart/*mixed* part. Change that to Multipart/*related*, and everything is fine (cf. http://tools.ietf.org/html/rfc2392).

This is structure of testcase1 (and testcase1b):

Content-Type: multipart/mixed; 
    boundary="----=_Part_23822_218390908.1343226472045"

------=_Part_23822_218390908.1343226472045
Content-Type: text/html; charset=UTF-8
    <img src="cid:logo-en">
    <img src="cid:coBrandLogo">

------=_Part_23822_218390908.1343226472045
MIME-Version: 1.0
Content-Type: image/gif; name=logo-en.gif
Content-Transfer-Encoding: base64
Content-ID: <logo-en>

------=_Part_23822_218390908.1343226472045
MIME-Version: 1.0
Content-Type: image/gif; name=coBrandLogo.gif
Content-Transfer-Encoding: base64
Content-ID: <coBrandLogo>
Content-Disposition: inline

So technically, we probably do the right thing.
However, TB could probably be more tolerant and accept correctly referenced inline images even in case of multipart/mixed.

Comment 9

[Thomas D. (:thomas8)]

Attachment: Testcase-1c.eml: With multipart/related instead of multipart/mixed, testcase-1b shows images correctly

After changing multipart/mixed to multipart/related, TB correctly shows referenced inline images of type <img src="cid:...">.

As explained in comment 8, imo TB should be more generous in handling this little flaw. Given the correct inline references to existing image parts, there's no reasonable doubt about the sender's intention of showing these images inline.

Comment 10

[Thomas D. (:thomas8)]

Eric, thanks for reporting this.

It has been reported before, dating back to Bug 61815 in the year 2000.
Please vote for that bug.

Comment 11

[Thomas D. (:thomas8)]

I'm always at war with FF browser cache undoing my changes...

Comment 12

[Eric]

(In reply to Jim Porter (:squib) from comment #7)
> Do you have "Show All Body Parts" enabled? That's the only way a recent
> version of Thunderbird should show attachments like "Part 1.1", and it will
> exhibit the problem described in comment 0. You should turn that off, since
> it's mostly for debugging and dealing with strange and broken messages.

In reply to this comment, the answer is "yes" I tried that, enabling "Show All Body Parts" and it did nothing to solve the problem.

Eric

Comment 13

[Eric]

(In reply to Thomas D. from comment #3)
> Created attachment 646026 [details]
> Testcase1.eml
> 
> Per comment 0, this message shows the bug (extracted from reporter's
> attachment 645765 [details], correct attachment this time)
> 
> Eric, thanks for providing testcase & screenshots. Pls avoid bundling
> testcase message and screenshots in a proprietary word document. It makes
> your testcase a lot harder to access and analyse.

Sorry about the proprietary.  I tried to search for the same bug and really couldn't say it was the same, in my mind, since I made the assumption that it was something new in TB as I didn't have the problem before a few months ago or a couple of months.  Now I realize it was probably a change/error made by the sending organization, who were probably correctly sending as multipart/related originally and then in an update to their EPP system, changed it to multipart/mixed, thus causing my problem.  I had been after them for a while to investigate and fix it, as I had suspected that originally, but when they couldn't come up with a solution I thought perhaps it was a TB problem just happened in a recent update.  Once again, my apologies for wasting peoples' time.   That being said, I certainly also agree with the reference to Comment 6 from Mitra as referenced by Thomas D