231759 - Can't double click to open message attachment in application/mac-binhex40

Status: RESOLVED FIXED

(MailNews Core :: Attachments, defect)

Description

[Mike Fedyk]

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]

Attachment: Bad Message attachment

Comment 2

[Boris Zbarsky [:bzbarsky]]

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]

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 [:bzbarsky]]

Yes, that's what comment 2 was about.

Comment 5

[Mike Fedyk]

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]]

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]

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]

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]

(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 [e-mail] instead)]

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)]

Filter on "Nobody_NScomTLD_20080620"

Comment 12

[:Irving Reid (No longer working on Firefox)]

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)