Build 20010831. 1. Set up helper application with following values: Set mimetype: audio/x-mpegurl Set suffix: m3u Set application: xmms %s OR Set application: /usr/bin/xmms OR Set application: /usr/bin/xmms %s 2. Restart browser. 3. Go to mp3.com and try to stream any mp3 (it will be an *.m3u file). 4. You get a pop-up asking you where to save file. Actual Results: Mozilla handles like any other unknown mime-type, asking you to save file. Expected Results: Mozilla launches xmms with m3u file. This behavior occurs whether or not the "Ask me before saving" flag is checked. The UI appears to work. The changes made through the UI appear to persist, and show up in the mimeTypes.rdf file. The only discrepancy is that I enter the extension as m3u, and it always shows up (even in mimeTyes.rdf) as M3U. This may be a duplicate of one of the numerous other Helper application bugs, but I am submitting as a separate bug until we figure out which one it is.
Does it work if you run Mozilla as root ?
I'm already running everything as root. I can run xmms just fine by itself. Streaming works fine through netscape 4.x when I set up the helper application there.
WFM with a current CVS build, Linux. I added /usr/bin/xmms (and not the additional %) Was promted to use helper app or save to disk. I remember that modifying helper types horked up my mimeTypes.rdf on an earlyer occation. Reporter: Can you attach that file in this bugreport You find the file in ./mozilla/Default/<salt>/
ahh i misunderstood this bug. Seems unchecking the box for "Ask before.." isn't at all honored. There are more bugs on this: bug 86531, bug 98115 Full path to helper app has no effect. It will launch once i confirm it in the prompting popup, but i have uncheced "Ask before" so it should have launched xmms without further delay.
No, the problem is that it simply doesn't work at all. No matter what I do, it seems, I never get mozilla to launch xmms. It simply won't launch it. I'm never prompted to use the helper type. The only option I ever get is to save to disk. Mozilla always handles the file as if it doesn't even recognize the mime type at all. Perhaps it is that mozilla automatically capitalizes the extension "m3u" to "M3U" when saving. But all files at mp3.com end in lower case "m3u". If mozilla is case sensitive, it would not recognize the type at all. To test this, I tried putting one of mp3.com's *.m3u files as a *.M3U file on my own web server, but I cannot properly test this case since I don't know how to set the server side mime types correctly. It simply loads the text of the file into the browser when I click on the file in this instance. Also, I am using the latest available download, which is 20010831, not a self build from the latest CVS source. Will try again with another mime type.
pdf has the exact same results: Set mimetype: application/pdf Set suffix: pdf Set application: /usr/bin/xpdf
there's so much there... i only got this when i added the helper app: <RDF:Description about="urn:mimetype:externalApplication:audio/x-mpegurl" NC:path="/usr/bin/xmms" NC:prettyName="xmms" /> <RDF:Description about="urn:mimetypes"> <NC:MIME-types resource="urn:mimetypes:root"/> </RDF:Description>
reopened bug 48948 is related.
Reporter, could you please try a clean profile and report the results? That mimeTypes.rdf looks like it's gone through a few mozilla releases that used slightly different mimeTypes.rdf formats....
I am seeing the same problem on OpenVMS. We use the "helper app" interface to define and invoke a PDF viewer when a page type of "application/pdf" is encountered. This used to work on OpenVMS, but now its not (not sure when it stopped working). I just blew away my mimetypes.rdf and re-added the helper app. Made no difference. Something is definitely broken here. Marking bug confirmed.
I should add that OpenVMS builds like a UNIX variant.
I just tried this on M0.9.3 and it didn't work there, so this has been broken for a while. I also tried on my M0.9.6 (tip) build from the end of last week, and that failed too - so it hasn't been fixed yet!
I stepped through this with the debugger to see if I could figure out what was going on. Well, from the mime type it managed to figure out the right helper app, and it access()'d that to make sure it existed. Everything was moving along real nice and then I hit this: // this code is incomplete and just here to get things started.. In LXR this line at: http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperApp Service.cpp#289 Is this why it doesn't work? Has this part of the code been rewritten but never completed? cc'ing mscott since his name is all over these changes, especially interesting is the change 1.72 in June with a comment "New Helper App design".
I am experiencing this bug as well (0.9.5 2001101202 on linux here). It doesn't even properly exec the application i specify for the mime type (only tested with m3u audio/x-mpegurl). So... I ran mozilla under strace. I saw the following (written from memory, not pasted; sorry) execve("/sbin", ["/sbin", "/home/greg/tmp/3Thgjkd.m3u"], [74 entries]) = EPERM (or was it EINVAL?) Regardless of what the actual error was, that's silly. why was it trying to execute "/sbin" instead of the configured application /usr/bin/xmms? Something strange is afoot at the circle K.
Anyone who works on this bug, see my postings to bug 115819. I'm sure this is the same problem, and I have some debug/trace info there.
Not sure if this is related, but I'm using Red Hat Linux 7.2 and the mozilla-0.9.7-0 rpm. Despite setting up an overriding entry for application/pdf, the default xpdf application is always run. This would imply that the mimeTypes.rdf file is just plain getting ignored. HTH
People who are having these issues should try a recent build (post-0.9.8). I've landed several patches lately to address problems with helper apps from prefs not being picked up (mostly case-sensitivity stuff). And then there's the problem Colin is describing which is an issue on Unix if you run as root.
-> file handler
->Future If we get feedback on Boris comment, and bug reports indicate that there's something more than the problem described in bug 115819, then we can move it up.
Annoying bug. It also exists on a Sparc Solaris 8 / mozilla 1.0rc1. I got it working with these steps: mv ~/.mozilla ~/.mozilla.old Under "Helper Applications" add the mime thing you want click on the appropriate link and choose "Open using ..." NEVER touch the "always ask before opening..." thing. Took me a while to figure this out. Looks kinda simple now doesn't it?
I have experienced this bug on RC 2 on linux. I run as root. Here is my scenario: I try clicking on an audio/x-scpls link for an mp3 stream. The link goes to a server which does a redirect to a listen.pls file on shoutcast. The save as dialog always pops up. http://www.bluemars.org/ is the url. No matter what I set for the helper app, this doesn't cause the helper app to work.
Dru, I think your problem is Bug 95828 (Running Mozilla as root prevents helper apps from launching). It affects me also. Unfortunately that bug seems to be inactive. Please put your comments there. Or vote for that bug.
Confirming on 1.0 RC 2, Mac OS 9.2.x. The behavior is as described in the first entry. Also noted that Moz converts upper-case extensions to all lower-case extensions for this platform also, and that clicking a link to a user-defined MIME type results in the browser displaying the file. Change platform affected to ALL?
Please keep this bug linux-only... especially since as far as I know this should now be fixed on Linux (this bug is worksforme, and I have yet to hear a Linux person say otherwise). Please file a separate bug on MacOS, cc me, and provide the urls at which you are seeing the bug as well as the contents of your mimeTypes.rdf file (as an attachment).
Still broken for me as of build-id 2002052020. The site is "http://www.buffyupn.com/video/bufa/bufapicker.html"; I have entries that should cover both Quicktime and Windows Media (see attachment). Boris - should I file a separate bug for FreeBSD, or is it better to mark this as a multiple OS issue?
Robert, that site only seems to have <object>s/<embed>s... we don't handle those with helper apps at all (bug 116027).
*** Bug 179245 has been marked as a duplicate of this bug. ***
This should be fixed in a recent build that includes the fix for Bug 86640. Reporter - can you try to reproduce this with a current build?
15 years ago
Marking worksforme due to lack of responses and inability to reproduce... If anyone is still seeing this (not with <object>, mind you), please reopen and provide the steps to reproduce...
I've also ran into this problem, because I used to put a %s on the line, which doesn't work. Now I've found out, that it's impossible to put any options to a helper application. Thinking about xmms, it would be nice to put a "xmms -e" in the helper application line, but unfortunately it doesn't work.
This works for me now as well. I can also just click on the link before any MIME type has been setup, point to the application, and have it work. Setup: mimetype: audio/m-mpegurl suffix: m3u application: /usr/bin/xmms If the issue is that templates such as "/usr/bin/xmms -e %s" are not honored, then that should be a different bug. This is just that NO helper applications were being honored.
Please don't use "closed"
I am the original reporter. Why should I not be able to close it?
Because "closed" should not be used in the Product "browser/Mailnews" Verified is the right state for a bug.