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

RESOLVED DUPLICATE of bug 61815

Status

Thunderbird
Message Reader UI
--
enhancement
RESOLVED DUPLICATE of bug 61815
6 years ago
6 years ago

People

(Reporter: Eric, Unassigned)

Tracking

14 Branch
Thunderbird 14.0

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Created attachment 645765 [details]
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.
Severity: major → normal
Summary: Inline images displaying at bottom of email → Inline images shown as file attachment
Created attachment 646023 [details]
Testcase1.eml

Per comment 0, this message shows the bug (extracted from reporter's attachment 645765 [details])
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.
Attachment #646023 - Attachment is obsolete: true
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.
Created attachment 646027 [details]
Screenshot1: First half of Testcase1.eml in message reader (with broken inline img)

(extracted from attachment 645765 [details])
Created attachment 646028 [details]
Screenshot2: Second half of Testcase1.eml in message reader (with supposed inline img as file attachment)

(extracted from attachment 645765 [details])
Attachment #646028 - Attachment description: Screenshot1: Second half of Testcase1.eml in message reader (with supposed inline img as file attachment) → Screenshot2: Second half of Testcase1.eml in message reader (with supposed inline img as file attachment)
Attachment #645765 - Attachment description: contains actual source of example email, and screen shots showing the viewing pane → Testcase1.doc: source of sample message + screen shots showing the viewing pane (see individual attachments below)
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

6 years ago
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.
Created attachment 646042 [details]
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.
Severity: normal → enhancement
Summary: Inline images shown as file attachment → Correctly referenced inline images <img src="cid:..."> should be displayed for cases of multipart/mixed instead of multipart/related
Created attachment 646047 [details]
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.
Eric, thanks for reporting this.

It has been reported before, dating back to Bug 61815 in the year 2000.
Please vote for that bug.
Severity: enhancement → normal
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 61815
I'm always at war with FF browser cache undoing my changes...
Severity: normal → enhancement
OS: Windows 7 → All
Hardware: x86_64 → All
(Reporter)

Comment 12

6 years ago
(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
(Reporter)

Comment 13

6 years ago
(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
You need to log in before you can comment on or make changes to this bug.