assign more than one helper application to one MIME type using file extensions

RESOLVED FIXED in mozilla1.6alpha

Status

Core Graveyard
File Handling
--
enhancement
RESOLVED FIXED
16 years ago
2 years ago

People

(Reporter: Detlef Grittner, Assigned: Biesinger)

Tracking

Trunk
mozilla1.6alpha
Other
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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
(Reporter)

Comment 2

16 years ago
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.
QA Contact: sairuh → petersen

Comment 4

15 years ago
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.

Comment 5

15 years ago
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?
ok
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 20

15 years ago
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.