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

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, enhancement)

Description

[Detlef Grittner]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Detlef Grittner]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Mårten Svantesson]

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

[Carsten Schlipf]

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.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

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?

Comment 8

[Boris Zbarsky [:bzbarsky]]

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?

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

that sounds good to me.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

the PATH bug is bug 56662 (just stumbled over it)

Comment 11

[Boris Zbarsky [:bzbarsky]]

biesi, want to take this then?

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

ok

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

actually, I think bug 65827 would be a better place for such a patch, if I
understand that bug correctly; marking dependency

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 16

[Boris Zbarsky [:bzbarsky]]

We may need to condition the query check on the scheme being http or https...

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 18

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: 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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 132078 [details] [diff] [review]
patch

r=bzbarsky

Comment 20

[Darin Fisher]

Comment on attachment 132078 [details] [diff] [review]
patch

sr=darin

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

Checking in nsExternalHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v  <-- 
nsExternalHelperAppService.cpp
new revision: 1.219; previous revision: 1.218
done