Closed
Bug 68009
Opened 24 years ago
Closed 23 years ago
Helper app doesn't launch when 'Ask me...' unchecked
Categories
(Core :: Networking, defect)
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.
Comment 1•24 years ago
|
||
I have this problem too - with xmms and realplay. Started for me in mid january.
Comment 2•24 years ago
|
||
Marking NEW as per comments.
Status: UNCONFIRMED → NEW
Component: Browser-General → Plug-ins
Ever confirmed: true
Comment 3•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
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>
Comment 7•24 years ago
|
||
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...
Comment 10•24 years ago
|
||
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".
Updated•24 years ago
|
Keywords: mozilla0.9,
nsbeta1
Comment 11•24 years ago
|
||
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.
Comment 12•24 years ago
|
||
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)
Comment 13•24 years ago
|
||
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)
Comment 14•24 years ago
|
||
*** Bug 76499 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
Bug #60812 seems to be related to this one.
Comment 16•24 years ago
|
||
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 ?
Comment 17•24 years ago
|
||
*** Bug 68736 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
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.
Comment 19•24 years ago
|
||
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
Comment 20•23 years ago
|
||
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 → ---
Comment 21•23 years ago
|
||
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.
Comment 22•23 years ago
|
||
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
Comment 23•23 years ago
|
||
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.
Comment 24•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Comment 25•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
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
Comment 27•23 years ago
|
||
That still doesn't fix it. Created bug 98084 until we can figure which, if any,
existing bug I'm currently experiencing.
Comment 28•23 years ago
|
||
Confirming the last comment. Linux build 2001083108.
Even with it set to
/usr/bin/xmms
and running as root, mozilla still prompts to download.
Comment 29•23 years ago
|
||
Ah, with the full path to the helper app it now works perfectly.
Comment 30•23 years ago
|
||
What build are you using ? It is not working for me with Linux 2001083108.
Comment 31•23 years ago
|
||
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 → ---
Comment 32•23 years ago
|
||
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).
Comment 33•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Comment 34•23 years ago
|
||
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.
Comment 35•23 years ago
|
||
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.
Description
•