Especially with the MIME type "application/octet-stream" there are problems when only one helper application can be used. For example I have associated "application/octet-stream" with xmms, so that I can open ".pls" files that are transfered with this MIME type. But there are other files with other extensions that can't be opened with xmms. By accident the extension ".exe" was associated with xmms in my case. If you could edit the extensions per MIME type and assign different file extensions to different helpers the behavior of Mozilla would be improved.
Um.. why are you assigning random stuff to application/octet-stream anyway? Make up a type for .pls files, assign it the .pls extension and things should work as long as no handler is assigned for application/octet-stream. Since the only types for which this would be useful are the "dumping ground" types application/octet-stream and text/plain, I suggest we not set up this cumbersome system...
Assignee: ben → law
Status: UNCONFIRMED → NEW
Component: Preferences → File Handling
Ever confirmed: true
Ah, I see. Mozilla chooses the helper application according to the extension of the file and not the MIME type. I didn't know that. Though it would be helpful if the pref dialog didn't only show the MIME type but also the file extensions in the "File types" list.
No, Mozilla chooses a handler based on the mime type. If there is no handler for the type, we look for a handler for the type that corresponds to the extension. Setting up a handler for application/octet-stream is not a good idea, since a wide variety of content gets served with that type (it's the "I don't really know what this is" type). So if there is no handler for it, we would fail that lookup, get the type corresponding to the extension, then look up the handler for that type.
There actually are cases when several handlers for one MIME type would be useful. What comes to my mind is application/postscript where an assignment to both ghostview (for previewing) and lpr (for printing) would be useful. You acctually also would wan't to be able to assign the roles like Preview and Print to handlers and have them presented to the user.
Boris, if I understand you right, then Mozilla Mail should open a file with the extension pdf, if there is a helper application for application/pdf with the extension pdf is specified, although it's attached to the mail as application/octet-stream and there is no handler for the mime-type octet-stream specified? I just tested that. No Chance (on Linux). It may work on Windows, were Mozilla might look in the registry for a handler for the file extension. But it does not work on Linux. This is even worse, since mailers like MS Outlook, send everything as application/octet-stream. No matter if it's a Word document, a JPEG image or a even a plain text file. So it really would be great, if mozilla would allow to open a file according to their mime-type and/or file extension. It would be great, if there helper applications could be assigned to either mime-type or file extension or both. At least if it's an unknown file path, it would be way better to open application using the PATH environment variable. Currently I have to specify the full path to an application in the "open with" field, altough it's in the path. IMO this is against the usual behaviour on Unix systems and it is annoying to have to look up for the full path of an known application and enter it in this field. Please allow me one off-topic comment: I have the impression, that Mozilla is more and more concentrating on features for Windows, but lacks on Unix/Linux. However the users of these platforms are one of the biggest user bases of Mozilla. Another example is the handling of the mail-biff sound, which only works on Windows, but reported a long time ago and never got fixed.
>Boris, if I understand you right, then Mozilla Mail should open a file with the >extension pdf, if there is a helper application for application/pdf with the >extension pdf is specified, although it's attached to the mail as >application/octet-stream and there is no handler for the mime-type octet-stream >specified? Hm... I don't think it would work. The extension is fetched from the URL, not the Content-Disposition header, so lookup will purely be based on the mimetype for mail attachments as the url doesn't have an extension (I kinda doubt taht mailnews uri impls support nsIURL) >It may work on Windows No, this is XP (Cross-platform) code. >At least if it's an unknown file path, it would be way better to open >application using the PATH environment variable. If I'm reading the code correctly, that should work. Doesn't it? (if it doesn't, that should be the issue of a separate bug; if you file one for that, please cc me) >Another example what is the first one? > is the handling of the mail-biff sound, which only >works on Windows, but reported a long time ago and never got fixed. Um. That works for me on Linux.
hm... bz: wouldn't it be better if this code here: http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#305 used the content-disposition header instead of the url extension, if it exists?
I think Christian has pretty much answered comment 5 (except the PATH thing; there is a bug on that, though, probably assigned to me). As for comment 7... That may indeed make sense; we need to put some thought into the security implications, but I think that with the isExecutable checks we have all over it should be OK. So I'd suggest using the header's extension and if there is none, using the URL extension unless it's a query (has a query string or POST data). Seem reasonable?
that sounds good to me.
the PATH bug is bug 56662 (just stumbled over it)
biesi, want to take this then?
Assignee: law → cbiesinger
actually, I think bug 65827 would be a better place for such a patch, if I understand that bug correctly; marking dependency
Depends on: 65827
ok this should be fixed by the bug 65827 checkin. But I'm leaving this open for now because I'd like to verify that.
sigh.... This works now for non-mailnews use cases. For mailnews, we have this problem: o) The channel does not implement nsIMultipartChannel (imho it should...) o) The filename of the attachment is fetched via ->GetFilename on the url, extension via GetFileExtension o) But: GetQuery returns a pretty long, definitely nonempty query string. This means we ignore whatever GetFile* would return.
We may need to condition the query check on the scheme being http or https...
I'd rather not do that if I can help it; my plan for this bug is to investigate whether making the mailbox: channel support nsIMultipartChannel would be doable...
Created attachment 132078 [details] [diff] [review] patch well, making it implement nsIMultipartChannel didn't really work out. so I'll go for bz's suggestion and check for http/https scheme.
Attachment #132078 - Flags: review?(bzbarsky)
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6alpha
Comment on attachment 132078 [details] [diff] [review] patch r=bzbarsky
Attachment #132078 - Flags: review?(bzbarsky) → review+
Attachment #132078 - Flags: superreview?(darin)
Comment on attachment 132078 [details] [diff] [review] patch sr=darin
Attachment #132078 - Flags: superreview?(darin) → superreview+
Checking in nsExternalHelperAppService.cpp; /cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v <-- nsExternalHelperAppService.cpp new revision: 1.219; previous revision: 1.218 done
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.