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.
14 years ago
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.
But the mime header in the message shows: --============_-1137409466==_============ Content-Id: <firstname.lastname@example.org.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.
Yes, that's what comment 2 was about.
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.
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/
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.
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
(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
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Filter on "Nobody_NScomTLD_20080620"
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)