Closed Bug 164257 Opened 22 years ago Closed 22 years ago

Handling of known MIME types and application/octet-streams is inconsistent

Categories

(MailNews Core :: Attachments, defect)

x86
Windows 98
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 58554

People

(Reporter: wolfson_uk, Assigned: mscott)

Details

... which leads also to the problem that helper applications can not be used efficiently at all. This problem shows e.g. with JPEG images (but I had them with different types of files such as .asf and .wmv video streams as well). I have defined my helper application, so that JPEG images from email attachments should be opened with my default image viewer, but with the requester opening to choose if I want to open or download first. Two problems here: 1. If the mail with the JPEG image comes from a different emailer, the image is often recognized as an "application/octet-stream" file. The download requester opens, but it does not have my preferred viewer entered as the choice to open the file with. Very inconvenient to always click through my directories to choose my viewer app ... 2. If the email comes from Mozilla (e.g. if I send it from one of my accounts to the other), clicking on the attached JPEG image causes Mozilla to display the image in the browser window. Even more inconvenient - it actually loaded an image over this bug report, when I was testing again while writing my report! Please note that I have also unchecked JPEG images in Preferences/Advanced/System because I do not want Mozilla to handle these. On the other hand, when I receive Excel (.xls) files which have no MIME type and are also recognized as an "application/octet-stream" Mozilla conveniently suggests to open them with soffice6 (OpenOffice 1.01) in the download window. When I receive Word files (.doc) which Mozilla recognizes as "application/word" MIME types, and also suggests to open them with soffice6, although I have no helper application defined for this MIME type. I have, however, set the default application for both file types in my Windows Folder options to soffice6, so this actually works fine from within Mozilla. It should be noted that it even works with the .xls file which has no MIME type, not even under the windows folder options. On the other hand, .jpg images are also set to be handled by my default viewer app in windows folder options, and they are not handled at all in the way I want them to be handled. Last not least, PDF files seems to work generally (I have defined the helper app and MIME type here), whether they are mailed by Mozilla, a different mailer, or found as a link on a website (I have deactivated the Acrobat plugin since I do not want to open the Acrobat Reader inside the Mozilla window). I would suggest that Mozilla handles email file attachments which have unknown or known MIME extensions generally in the following order: 1. If a helper application for the MIME type is defined, suggest this helper app to open the file with. 2. If the MIME type is "application/octet-stream" but the file extension matches that of a MIME type for which a helper application is set, suggest this helper app to open the file with. 3. If no helper application is defined for a MIME type, which is however recognized by Mozilla, suggest the application which is set as default for this MIME type in the windows folder options. 4. If the MIME type is "application/octet-stream" and there is no helper application specified that uses this file extension, suggest the application which is set as default for this file extension in the windows folder options. 5. If none of the above, there is probably nothing to suggest by default.... I actually think this this is a problem that causes major inconveniences, and hope someone can have a close look at it soon ...
Target Milestone: --- → mozilla1.1beta
> 2. If the MIME type is "application/octet-stream" but the file extension matches > that of a MIME type for which a helper application is set, suggest this helper > app to open the file with. That is _exactly_ what should be happening. What version of Mozilla are you using? Do you have application/octet-stream listed in helper app preferences?
Target Milestone: mozilla1.1beta → ---
I have been using Mozilla 1.1 beta, and since today Mozilla 1.1 (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826) I don't have application/octet-stream defined in my helper apps, because these might be any unknown file format, and I am happy that e.g. Excel files who come as application/octet-stream MIME types are recognized by their .xls extension, and Mozilla suggest soffice6 (Open Office) to open the file, as I have set it in my systems folder options->file types. I have however defined a MIME type for image/jpeg for all files with extensions .jpg, .jprg, .jpe . But Mozilla does not recognize these extensions when attached JPEG images come as application/octet-stream MIME types, and does not suggest the helper application (IrfanView) I have defined for the image/jpeg MIME type. Irfan view is also set as my systems default application for .jpeg files in folder options->file types.
I'm having the same inconsistency in Mozilla running on Macintosh, if I set up a file extension and MIME type with the extension mapped to the software I need to use, and a mail attachment of that type arrives, Mozilla doesn't recognizes the MIME type I defined on the Preferences/Helper Applications, it also bypasses the MIME/extension configuration of the operating system. It just shows a "application/octet-stream". This problem is stoping the deployment of Mozilla as the main browser in my company.
This bug should be changed to ALL OS, my problem is with Mozilla 1.1 on Mac OS and Windows 2000
QA Contact: trix → yulian
QA Contact: yulian → stephend
ok, this is just a bug in the way we pull the MIME info for types we handle internally... *** This bug has been marked as a duplicate of 58554 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.