Closed Bug 68009 Opened 24 years ago Closed 23 years ago

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

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dwp, Assigned: mscott)

References

(
URL
)

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: 23 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: 23 years ago → 23 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 ago → 23 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.