149072 - included GIF images not displayed properly

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect)

Description

[samuel]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523
BuildID:    build 2002060107

Included GIF images do not display properly in the mail viewer.

It Displays properly with netscape 4.79 mail

Reproducible: Always
Steps to Reproduce:
1.Copy the attached file to a mail folder
2.view the resulting message
3.

Actual Results:  broken image icons

Expected Results:  pretty pictures

This problem appears to have been occurring for quite some time. 
(it appears to have been broken since at least the RedHat7.1 release).

(I can also attach a screendump, if you wish)

Comment 1

[samuel]

Attachment: A sample of the email that doesn't display properly

This problem appears to be with GIF attachments.

GIFs display fine in regular web pages (or if simply referenced on external 
webservers from within the HTML mail)

If I double-click on the image name in the attachment window, it displays fine.

Comment 2

[samuel]

I just noticed that both GIFs and JPEGs are included in the email.. Neither GIFs
nor JPEGs are being displayed.

Comment 3

[dieco]

also happens on win95

Comment 4

[Joel Nelson (don't send email)]

I'm attaching two more e-mail messages affected by this.
Mozilla 2002070203
Mac OS X

Comment 5

[Joel Nelson (don't send email)]

Attachment: One affected HTML e-mail message on Mac OS X

Comment 6

[Joel Nelson (don't send email)]

The other message is 450 KB -- too large to upload to Bugzilla.  Let me know and
I can forward it.   Both are HTML format -- don't view as plain text or the
message won't look right and the bug may not be exposed.

Comment 7

[Jean-Francois Ducarroz]

Mozilla is not able to display the first sample message because the image parts
use contend-id  instead of content-location!

Mozilla is not able to display the second sample because the image parts have a
content-type unknow/unknow!

I don't know yet if those 2 problems violate the RFC but both Netscape
Communicator and Outlook are able to display correctly the message...

Comment 8

[Jean-Francois Ducarroz]

Attachment: Proposed fix, v1

This patch addresses only the first problem (content-location used instead of
content-id). I did not fix the second problem (invalid content-type) because
that would re-open a potential security hole in Mozilla. We decided a while ago
to restricted related part that we accept to display inline to well know
content-type. unknown/unknow is not a valid one!

Comment 9

[Jean-Francois Ducarroz]

Comment on attachment 93331 [details] [diff] [review]
Proposed fix, v1

This fix cause a regression. Embedded remote image are not shown anymore!

Comment 10

[Jean-Francois Ducarroz]

Comment on attachment 93331 [details] [diff] [review]
Proposed fix, v1

forget about my previous comment, the patch is good. I forget that I have the
pref to block remote image in email set!!!!!

Comment 11

[varada]

Comment on attachment 93331 [details] [diff] [review]
Proposed fix, v1

r=varada; We are getting rid of that code when location already has value of
content-location header. Regarding the second part displaying content-type
unknown/unknown would open a security hole and that is good reason for not
doing it even if Netscape Messenger or OE does it.

Comment 12

[David :Bienvenu]

so we're dropping support for content_location, is that it? in the sample
messages, it looks like the content location is just the file name, and not the
actual location...is that really what content_location is supposed to be?

Comment 13

[Jean-Francois Ducarroz]

no, the patch made Mozilla support content-location when no content-id are
specified. The old code that was there for that was bogus, removing it made that
feature works again. We have other code about content-location that I haven't
removed or touched as it was working fine.

Comment 14

[David :Bienvenu]

Comment on attachment 93331 [details] [diff] [review]
Proposed fix, v1

ok, thx, that was the missing piece of info. sr=bienvenu

Comment 15

[Jean-Francois Ducarroz]

Fix checked in the trunk

Comment 16

[esther]

The first sample message was an e-weather forcast sent to an email account from
WeatherOffice "[e-mail]".  The sample attached to this bug doesn't
show the images so I set up an account to receive these forcasts.  The forcasts
come in and the images are displayed with trunk build 20021118 on linux, macosx
and winxp.  The fix for this bug fixed the 1st sample message
(content-location), but the 2nd sample message (content type unknown ) will not
be fixed.  Verified fixed in trunk only.