Closed Bug 133580 Opened 22 years ago Closed 22 years ago

mail fails to show or allow access to .tiff file attached

Categories

(MailNews Core :: Attachments, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: erict, Assigned: mscott)

References

Details

(Whiteboard: [adt1])

Attachments

(2 files)

received a message with a .tiff image file attached to it.  
message does not indicate it has an attachment.  nor can i get at it through UI.

header has 
Content-Type: mixed/multipart; boundary="----------somebignumber"

see attachment (if i can get it to work)

seen in linux build: 2002032608
notice no attachment pane thing.
notice content-type header field.

also: 
there is no "Attachments" sub menu in the File menu.

when i forwarded the message to myself the atachment was still missing
(although it may have just been dropped by the forward).
*** Bug 133579 has been marked as a duplicate of this bug. ***
*** Bug 135637 has been marked as a duplicate of this bug. ***
OS: All. Resolving as new based on dup bug 135637.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
I also have faced this problem, and I think that it is related to the MIME handling:
The attached image was really a .gif, but it didn't appear in the attachments
pane. Also, the mail didn't get marked as read, it was just like id didn't
finished loading or something like that.
Looking at the source of the message I saw that it came with:
Content-Type:  image/tif;
(I think it was /tif, but it also could have been /tiff)
so I closed mozilla edited the inbox file and replaced the image/tif with
image/gif, and now I can access the file.

This evening I've been searching for a bug that I thought that I've read
recently about this problem but i've been unable to find it (it was specifically
pointing a failure in a test of MIME handling)
I have the same problem. Attachments of content-type image/tiff are
inaccessible. With further testing, it appears like any image/* content-type
that is not handled internally (as e.g. image/gif is) is not working. The same
applies to "implicit" attachments, i.e. non-multipart mails, that have
content-type: image/tiff.

So it might indeed be a MIME component bug, but I don't think there's a similar
bug filed there already.
*** Bug 136567 has been marked as a duplicate of this bug. ***
nominating nsbeta1
Keywords: nsbeta1
This bug is not new - it was "implemented" shortly after 0.9.9-branch was cut
off. So this bug is not yet in 0.9.9 release but since very early 0.9.9+
nightly's (!!)

I strongly recommend to fix this bug not later than 1.0 release! 

And it is *not* a problem of "image/tif", as I get the mails this way:

--NEXT_PART_1017829726_44847029_14333
Content-Type: image/tiff; name="f28b2816.tif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="f28b2816.tif"


From - Wed Apr 03 12:29:01 2002
X-UIDL: e8d361580bbee61a6f7685e006967e62
X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
Return-Path: <gmxfaxgate@gmx.net>
X-Flags: 0000
Delivered-To: GMX delivery to emig@gmx.com
Received: (qmail 19751 invoked by uid 0); 3 Apr 2002 10:28:46 -0000
Received: from gate.gmx.net (HELO thor2.v300.gmx.net) (213.165.64.17)
  by mail.gmx.net (mp006-rz3) with SMTP; 3 Apr 2002 10:28:46 -0000
To: emig@gmx.com
From: gmxfaxgate@gmx.net
Subject: 2 Seite(n) Fax von
MIME-Version: 1.0
X-Mailer: POSTIE (Mar 16 2000 10:41:35)
Date: Wed, 03 Apr 2002 12:28:46 +0100
Content-Type: multipart/mixed; boundary="NEXT_PART_1017829726_44847029_14333"
Message-ID: <20020403102847.19793gmx1@mp006-rz3.gmx.net>


--NEXT_PART_1017829726_44847029_14333
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Sent by http://www.gmx.net


--NEXT_PART_1017829726_44847029_14333
Content-Type: image/tiff; name="f28b2816.tif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="f28b2816.tif"

SUkqABj0AAAAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoAB
TZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2a
[continued]


PS: The bug showed up in the nightlies 0.9.9+ that were built before 0.9.9 was
released, I'm sure as I had to stop using nightly build then because of this bug.
As I feared: This bug is not fixed in rc1 - This makes me and everybody who uses
TIF-Attachments quite often (for example most fax-gateways use TIF) unable to
use any release beyond 0.9.9 :-(
For me and many others I know, this is BLOCKING and I have to change to a
different mail-application. Maybe kmail on Linux...

ALL faximiles, I reciieve (~10-20/week) are sent via email to me and currently I
have no chance to same the attached file. Currently I forward them to an
GMX-Account, so that I am able to save them, but this is not the solution!

It really can not be that hard to fix it. Before 0.9.9, all worked perfect.

And I am quit sure, this will be a a major point for many people to choose a
different mail-application what normally also includes choosing a different
browser. :-(((

I also have submitted a bug concerning this problem (Bug 136567 - marked as dupe
of this), because not seeing the attachment is not the only problem that
occures. Here on my system, when I click on the msg, it does not change ists
state but keeps being "unread" all the time.

Maybe more people can comment this issue.
Regarding the "msg says unread" problem: that works ok for me. The message gets
marked as read, once I select another message. If you think this should be
changed, you might want to file a new bug report (unless there is one already ;))
Is this just tiff, or can someone duplicate it with another content-type?
*** Bug 138757 has been marked as a duplicate of this bug. ***
*** Bug 138955 has been marked as a duplicate of this bug. ***
*** Bug 139138 has been marked as a duplicate of this bug. ***
I sent myself various e-mails (from withing Mozilla itself) with image atrtachments.
TGA attachment had no problem. PCX attachment had no problem.
TIF attachment never shouwed up nor got the "read" flag.

Definitely something about TIF itself and not "not internal image formats".
Attached patch the fixSplinter Review
In the case of images which mozilla is unable to render itself, we were failing
to set the mime class to be an external object. This prevented the image from
showing up in the attachments list.
this bug gets duped quite a bit and should go into moz 1.0. I'll get the reviews
now.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Attachment #80419 - Flags: review+
Comment on attachment 80419 [details] [diff] [review]
the fix

r=ducarroz
Attachment #80419 - Flags: superreview+
Comment on attachment 80419 [details] [diff] [review]
the fix

sr=bienvenu, awesome, I ran into this this weekend.
*** Bug 137215 has been marked as a duplicate of this bug. ***
fixed on the trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Keywords: mozilla1.0
Trix, can you test this fix on the trunk and update the bug with your results.
Thanks.
updating impact.  Not providing access to attachments is very serious.
Whiteboard: [adt1]
Marking adt1.0.0+, please check into the branch (when it is open, of course :-)
Keywords: adt1.0.0adt1.0.0+
Works for me now with 2002042403 build. Thanks!
Comment on attachment 80419 [details] [diff] [review]
the fix

a=scc for checkin to the mozilla 1.0 branch
Attachment #80419 - Flags: approval+
fixed on the moz 1.0 branch.
Keywords: adt1.0.0+fixed1.0.0
verified on mozilla branch 2002042506 and netscape branch 2002042506
Status: RESOLVED → VERIFIED
changing keyword fixed1.0.0 to verified1.0.0
*** Bug 140446 has been marked as a duplicate of this bug. ***
Is there a secret way to get to the attachment after installing 20020424?  

I want to know for sure before asking the person to resend. I'm using 2002042406
now but don't see the attachment still. Thanks. 
Susie, if a bug was checked in on the 24th then it won't be available till the
next day's release builds. This bug was checked into the branch on the 24th. You
need to be using a branch build from the 25th or greater in order to get this fix. 

You don't need the person to resend the message. Just get a new build and view
the same message. You'll see it in the attachment list. 
*** Bug 140890 has been marked as a duplicate of this bug. ***
*** Bug 141072 has been marked as a duplicate of this bug. ***
*** Bug 141500 has been marked as a duplicate of this bug. ***
*** Bug 142126 has been marked as a duplicate of this bug. ***
*** Bug 142302 has been marked as a duplicate of this bug. ***
*** Bug 142709 has been marked as a duplicate of this bug. ***
*** Bug 143476 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: