Last Comment Bug 231759 - Can't double click to open message attachment in application/mac-binhex40
: Can't double click to open message attachment in application/mac-binhex40
Status: RESOLVED FIXED
:
Product: MailNews Core
Classification: Components
Component: Attachments (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 310898 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-21 14:48 PST by Mike Fedyk
Modified: 2012-07-23 19:03 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Bad Message attachment (160.07 KB, message/rfc822)
2004-01-21 14:54 PST, Mike Fedyk
no flags Details

Description Mike Fedyk 2004-01-21 14:48:27 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031225 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030

I can save the file to the desktop and open it from there with no problems, but
double clicking on the attachment in mailnews won't launch acrobat reader.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Mike Fedyk 2004-01-21 14:54:45 PST
Created attachment 139616 [details]
Bad Message attachment
Comment 2 Boris Zbarsky [:bz] 2004-01-21 19:33:44 PST
The filename our binhex converter is getting out of that binhex file is 'MATCH
MAIL_CRX', which tells it nothing about this being a pdf file....

Really, the converter may need to ask the channel for a filename or something,
but there is no decent necko api to do that.

I'm not really sure sure whether that's the heart of the problem here, though. 
I'd expect that we would end up in the "unknown content" branch in
nsBinHexDecoder::SetContentType and then sniff the content as a pdf.
Comment 3 Mike Fedyk 2004-10-21 12:20:35 PDT
But the mime header in the message shows:

--============_-1137409466==_============
Content-Id: <a05010400bc3482104ae6@[192.168.20.229].0.0>
Content-Type: application/mac-binhex40; name="MATCH_MAIL_CRX.pdf"
Content-Disposition: attachment; filename="MATCH_MAIL_CRX.pdf"
 ; modification-date="Wed, 21 Jan 2004 11:10:31 -0800"

I would assume the mac mail client is adding the ".pdf" to the mime portion for
windows client compatability after it has found info in the resource fork that
it is a pdf file.  So "MATCHMAIL_CRX" would be the correct file name on the mac
side, but mozilla/tb should be looking at the mime header also.
Comment 4 Boris Zbarsky [:bz] 2004-10-21 12:34:05 PDT
Yes, that's what comment 2 was about.
Comment 5 Mike Fedyk 2004-11-10 18:53:46 PST
You would need a filter for each file type to do that.  Why not just take the
extension (after size and bad char checks of course), push it to the mime system
and see if it has an association.

You can encode any file type in binhex, so why parse the content when the
message is already giving you hints.

If there are no hints then of course we would need file type matching code.

I just saved the message attached to this bug and found that TB 0.9 (20041103)
is already using the name="MATCH_MAIL_CRX.pdf" mime header for the filename for
the "save as" process.  It should do the same for the temporary file created
during the "run" process.
Comment 6 Gervase Markham [:gerv] 2005-09-27 02:04:19 PDT
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Comment 7 Mike Cowperthwaite 2005-10-07 08:08:58 PDT
A similar issue is reported at bug 310898; note that the attachment at that bug 
was generated by Thunderbird running on a Mac.

Note that the attachment from this bug, as at the other, is shown (for me, 
testing with TB 1.5/1.6) with a WinZip icon.
Comment 8 Katsuhiro MIHARA 2006-08-01 08:56:09 PDT
Same report exists in Bugzilla-jp (written in Japanese)
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5278

At that bug,
1. TB mistakes that a PDF file's mime-type is "application/mac-binhex40".
2. TB makes MIME header "Content-Type: application/mac-binhex40".
3. TB sends that file's data fork. "application/mac-binhex40" is "7bit clean", so TB sends with "Content-Transfer-Encoding: 7bit"

Replacing mimeTypes.rdf of TB with one that regists *.pdf file's mime-type is "application/pdf".

Mac developers mentioned that urlloader relies on old Internet Config and should be rewriten. But there is no action in nine months.
Bug 301731(Bug 4591): Rewrite uriloader mime type handling on OS X

TB has no option to define a custom mime-type. Users needs Seamonkey to create mimeTypes.rdf.
Bug 244618 : Need an option to define a custom mime-type (for attaching files)
Bug 229386 : Thunderbird ignores many of mimeTypes.rdf entry copied from
Mozilla, even though mimeTypes.rdf is empty and no way to define mimeTypes.rdf entry
Comment 9 Katsuhiro MIHARA 2006-08-01 08:57:40 PDT
(In reply to comment #8)
> Bug 301731(Bug 4591): Rewrite uriloader mime type handling on OS X

Please ignore Bug 4591. That is mistaken.
# bug number at Bugzilla-jp
Comment 10 (not reading, please use seth@sspitzer.org instead) 2007-06-21 15:23:43 PDT
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Comment 11 Serge Gautherie (:sgautherie) 2008-06-20 10:48:45 PDT
Filter on "Nobody_NScomTLD_20080620"
Comment 12 :Irving Reid (No longer working on Firefox) 2012-07-23 19:02:42 PDT
This appears to be fixed by bug 489864 (and to be a duplicate of bug 310898); I have tested and verified that TB no longer generates incorrect MIME types for PDF attachments (tested on OS X 10.7)
Comment 13 :Irving Reid (No longer working on Firefox) 2012-07-23 19:03:15 PDT
*** Bug 310898 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.