Closed Bug 68009 Opened 24 years ago Closed 23 years ago

Helper app doesn't launch when 'Ask me...' unchecked

Categories

(Core :: Networking, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dwp, Assigned: mscott)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-ac12 i686; en-US; m18) Gecko/20010204 BuildID: 2001020409 When a helper application is configured using the "Handled By: Applicaton" radio button in the MIME type configuration, and the checkbox "Ask me before opening downloaded files of this type" is unchecked, Mozilla does not launch the helper app. I'm having this difficulty specifically with launching gv to view files. Reproducible: Always Steps to Reproduce: 1. Set up application/pdf as a MIME type handled by gv. Check the 'Ask me before opening downloaded files of this type' box. Confirm that gv launches properly when a PDF link is clicked on. 2. Go back into the configuration and uncheck the box. 3. Try clicking on PDF links. Actual Results: Mozilla turns the link the clicked color when clicked, and displays "sending request to [servername]" in the statusbar, but the animation in the top right corner does not run and the statusbar soon says "Document: Done". Expected Results: Mozilla should pop open the file download dialog, download the file in question, and launch gv to view the file.
I have this problem too - with xmms and realplay. Started for me in mid january.
Marking NEW as per comments.
Status: UNCONFIRMED → NEW
Component: Browser-General → Plug-ins
Ever confirmed: true
I am seeing this problem as a regression for 0.8 (the helper is launched successfully with 0.7). I also built from CVS (2001-02-17) and the problem is there as well. To make sure it wasn't a change in the mimeTypes.rdf format or some such thing, I renamed my ~/.mozilla so that the mozilla with the problem would create a new profile. For example, I first visit an m3u URL at mp3.com and I get a download/open dialog. If I navigate to xmms, that works. However if I set up a new MIME type using Edit->Preferences->Navigator->Helper Applications using the method that works in previous versions (using Edit to uncheck the "ask me before downloading" box) and restart mozilla, when I again click on the m3u link, this time nothing happens (no dialog, no nothing). So the creation of the new MIME type did have an effect. In the case of the CVS version, I see this in the output: Document http://chooser.mp3.com/cgi-bin/play/play.cgi/AAIBQojMCQDABG5vcm1QBAAAAFI30wEAUQEAAABDDK2AOgVCf072uOJDwr0M6JOt6Pk-/aria.m3u loaded successfully but xmms is not launched. This is only an example. The problem exists for other MIME types as well.
I am not sure if this is the same bug, but after I upgraded from 0.7 to 0.8 (as a precompiled .tar.gz package for Linux) *none* of my helper applications work anymore. They work fine if I go back to 0.7. All helper applications have been configured for correct mime types through the Preferences dialog. I see no output in the xterm window upon failure of a helper's launch.
reassigning and adding law to cc: list
Assignee: asa → mscott
I have noticed this annoying bug in 0.8 as well.. However I think I have it working... I deleted my mimeTypes.rdf started Mozilla.. then created a new mimetype.. and the one thing I did differently is i didn't put a . before the extension.. The only problem is it seems to be ignoring my "don't ask" setting and always asking. here is the RDF stuff for my "i believe working" xmms audio/x-mpegurl mimetype <?xml version="1.0"?> <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <RDF:Description about="urn:mimetypes"> <NC:MIME-types resource="urn:mimetypes:root"/> </RDF:Description> <RDF:Description about="urn:mimetype:handler:audio/x-mpegurl"> <NC:alwaysAsk>false</NC:alwaysAsk> <NC:externalApplication resource="urn:mimetype:externalApplication:audio/x-mpegurl"/> </RDF:Description> <RDF:Description about="rdf:#$iIIwP2"> <RDF:type resource="http://home.netscape.com/NC-rdf#externalApplication"/> </RDF:Description> <RDF:Description about="urn:mimetype:audio/x-mpegurl"> <NC:value>audio/x-mpegurl</NC:value> <NC:description>Mpeg URL</NC:description> <NC:editable>true</NC:editable> <NC:fileExtensions>M3U</NC:fileExtensions> <NC:fileExtensions></NC:fileExtensions> <NC:handlerProp resource="urn:mimetype:handler:audio/x-mpegurl"/> </RDF:Description> <RDF:Description about="urn:mimetype:externalApplication:audio/x-mpegurl"> <NC:path>/usr/bin/xmms</NC:path> <NC:prettyName>xmms</NC:prettyName> </RDF:Description> <RDF:Seq about="urn:mimetypes:root"> <RDF:li resource="urn:mimetype:text/html"/> <RDF:li resource="urn:mimetype:audio/x-mpegurl"/> </RDF:Seq> <RDF:Description about="urn:mimetype:text/html"> <NC:value>text/html</NC:value> <NC:description>Hypertext Document</NC:description> <NC:editable>false</NC:editable> <NC:fileExtensions>htm</NC:fileExtensions> <NC:fileExtensions>html</NC:fileExtensions> <NC:handlerProp resource="urn:mimetype:handler:text/html"/> </RDF:Description> <RDF:Description about="urn:mimetype:handler:text/html"> <RDF:type resource="http://home.netscape.com/NC-rdf#handler"/> <NC:saveToDisk>false</NC:saveToDisk> <NC:handleInternal>true</NC:handleInternal> <NC:externalApplicationProp resource="rdf:#$iIIwP2"/> </RDF:Description> </RDF:RDF>
And it doesn't work.... I quit and restarted mozilla and it didn't work until I changed the alwaysAsk to true in the RDF file...
*** Bug 72671 has been marked as a duplicate of this bug. ***
Changing the component to networking.
Component: Plug-ins → Networking
Why does this bug have an undefined Priority setting? Does that mean it is "less than unimportant"? And why is the severity not Major? My understanding of the current state of this is that helper applications simply do not work at all (unless someone has a workaround). If there is no known workaround, it would seem to fit the definition of "major loss of function".
Keywords: mozilla0.9, nsbeta1
I have discovered that there IS a workaround. Somehow, I just figured out something that must be obvious to most people, namely that a plugin can in principle handle *any* MIME type, including one normally handled by a helper app. Plugger seems to be designed for this purpose. I have been able to use it to get "helper app-like" behavior for various types that I used helpers for in 0.7.
Hello, The same problem exists in the MSWindows version. Tested with Gecko/20010417 on WIN2K. I have noticed that: 1. The "Ask me..." option changes only after quiting & restarting mozilla 2. The helper app doesn't start if "Ask me.." is unchecked AND 3. The temporary files ARE created *correctly* (but are never removed, see 63105)
Hello, The same problem exists in the MSWindows version. Tested with Gecko/20010417 on WIN2K. I have noticed that: 1. The "Ask me..." option changes only after quiting & restarting mozilla 2. The helper app doesn't start if "Ask me.." is unchecked AND 3. The temporary files ARE created *correctly* (but are never removed, see 63105)
*** Bug 76499 has been marked as a duplicate of this bug. ***
Bug #60812 seems to be related to this one.
Blocks: 78106
On build 2001042906 (Linux) I have the following Helper Application defined Extension: PLS MIME type: audio/x-cpls Application: /usr/bin/xmms Ask me: False Then I go to http://www.shoutcast.com/ and when I try to listen to some music nothing happens. I'm sure this worked before. If I change "Ask me: true", it works correctly. When I switch the "Ask me" option I have to restart Mozilla to take effect. Is that an expected behaviour ?
*** Bug 68736 has been marked as a duplicate of this bug. ***
This appears to me to be fixed in latest CVS. Also, I am able to change from "ask" to "don't ask" without having to restart Mozilla for it to take effect. Now, in "don't ask" mode, the dialog window still comes up for a second, but goes away by itself and the helper is then launched successfully. While it seems to me that this should not happen, it isn't really a problem.
Just tried it in Build Id 2001051815 on RedHat 7.1 - works fine. I do not see the dialog window coming up (even for a moment), I only see the download progress window.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Build on Sept. 1, 2001 (Linux). Helper apps don't work at all. I replicate this with trying to stream m3u files from www.mp3.com. This is a very annoying issue that keeps recurring. After entering data in the UI, this is what it puts in mimeTypes.rdf. It doesn't work. No matter whether the "Ask me..." is check or unchecked, I am asked to save the file to disk as if it was a completely unrecognized mimetype/file extension. <RDF:Description about="urn:mimetype:audio/x-mpegurl" NC:value="audio/x-mpegurl" NC:description="mp3 stream" NC:editable="true"> <NC:fileExtensions>M3U</NC:fileExtensions> <NC:fileExtensions>.M3U</NC:fileExtensions> <NC:fileExtensions></NC:fileExtensions> <NC:handlerProp resource="urn:mimetype:handler:audio/x-mpegurl"/> </RDF:Description> <RDF:Description about="urn:mimetype:externalApplication:audio/x-mpegurl" NC:path="xmms %s" NC:prettyName="xmms %s" /> <RDF:Description about="rdf:#$1bFxD2">
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Please try again with a new profile. There haven't been any linux tarballs today so I can't test (I can play m3us from mp3.com on yesterday's linux build) but your problems may be the result of some changes that have landed over the past couple days for other helper-app bugs.
No, deleting the entire ~/.mozilla directory and starting from scratch did not help at all. It's the latest downloadable tarball for Linux so it may not be Sept 1. I was just describing the date at which I downloaded the "latest" tarball (i.e., nightly build). In any case, I don't see what there might differ between our systems that would cause it ot work on one but not the other. Perhaps I am installing the mime type incorrectly? I am following xmms.org's advice, which works fine for 4.x: "... And for http://www.mp3.com Set mimetype: audio/x-mpegurl Set suffix: m3u Set application: xmms %s ..." from http://xmms.org/documentation.html
I have this problem too, I can't get any helper application to work from Moz, eg. PDF, mp3, wav. The dialogue comes up asking whether to use the helper application, saying yes downloads the file but no app is started as far as I can tell. Q: should the helper spec include anything for the command line params, eg should it be 'xmms %s' or just 'xmms'? I'm using the 0.9.3 release but this has been the same since 0.8. I've just deleted .mozilla as advised and still see the problem.
Steve, will the helper app launch correctly when "Ask me" is checked and fail to launch when it is unchecked? If it always fails to launch, then it has nothing to do with this bug and is probably related to one of the many bugs tracked by bug 78106. My guess is that you are seeing the bug 56662 "Cannot load helper apps unless app has full path" and/or bug 57420 "no support for heler app command line args". To answer your question - both choises are *wrong* for Mozilla. It should be "/full/path/to/xmms" (e.g. /usr/bin/xmms or whatever the correct path is).
Status: REOPENED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
Aleksey: I have tried all options presented. It is not "helper app does not handle args properly" because the helper app is never launched. It is not "full path must be specified" because that doesn't work either. But I guess it's not this bug either. Helper apps simply don't work at all (at least on Linux, build 20010831). I'll have to open a new bug.
Bug 57420 is much more thenn just "helper app does not handle args properly" it's "nothing works if you try to specify args". Currently, in Mozilla helper app has to be the full path to the helper app *and nothing else*. If you have put any arguments into the helper app field, or if you have put " %s" or just a space symbol at the end, Mozilla will conisder it to be a part of the path and will fail to launch the app. path="xmms %s" will not work per bugs 56662 and 57420 (note that each of them alone is sufficient to prevent it from working). Only path="/full/path/to/xmms" should work
That still doesn't fix it. Created bug 98084 until we can figure which, if any, existing bug I'm currently experiencing.
Confirming the last comment. Linux build 2001083108. Even with it set to /usr/bin/xmms and running as root, mozilla still prompts to download.
Ah, with the full path to the helper app it now works perfectly.
What build are you using ? It is not working for me with Linux 2001083108.
Reopening. This is not working with Linux 2001090408. I am running as root. I have the following in helper apps: audio/x-mpegurl Extension: M3U Application: /usr/bin/xmms I have tried with ask me checked, and with it unchecked. It ALWAYS brings up the save dialogue, no matter what.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ditto on 2001090409/Linux. The helper app is remembered after hitting "Advanced..." and configuring it, but the dialog always appears with "Ask me..." still checked, even after I uncheck it. As a side note, "Advanced..." detects the extension as "cgi" and not m3u (at mp3.com, anyway).
Please do not reopen this bug unless you have the following condition: - when "ask me" is checked, everything works correctly. - when it is unchecked, the helper app would not start *at all* (even after a dialog). gabriel, what you are describing seems like bug 48948 ``download options dialogue doesn't save preferences ["Ask me before opening..."]'' and/or bug 93173 ``Helper app decision isn't remembered [using Open for non-OS-defined types]''
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
IT DOES NOT WORK FOR ME AT ALL, regardless of whether 'ask me' is checked or unchecked. Mozilla DOES remember my settings (checked/unchecked), that is not the bug I am seeing. Please reopen the bug, it is NOT fixed for me.
gabriel, why do you insist on reopening *this* bug!? If it happens regardless of whether 'ask me' is checked, then it is a *different bug*! Please take a look at the list of bugs that bug 78106 depends on and if you do not think your bug is one of those, please open a new one.
You need to log in before you can comment on or make changes to this bug.