Build ID: current CVS trunk pull If you have configured a helper application for something but have gotten the path, the program name, or whatever wrong such that it won't run, Mozilla will be completely silent about this failure. This is especially easy to do these days, seeing as Mozilla doesn't support command line switches for helper apps at the moment. Reproduction: 1. configure a helper app for application/pdf. Get it wrong: supply a wrong absolute path, give a switch (ideally a bogus one), etc. 2. visit a PDF file. Look, no error message. Look, no PDF file being shown. Suggested fix: if the attempt to start the application fails, or if the application exits with a status besides 0, Mozilla should pop up a dialog saying 'the attempt to start the helper application failed' and then offer you a chance to save the just-downloaded file to somewhere.

confirmed on build 2000110706, linux/Mandrake 7.2.

Added self to CC. I'm seeing this on RedHat 6.2, CVS build from 11/6/2000. I've seen this since at least M17.

I see a smiliar problem on mac... but it's not particular to having a bad path or such. What I see happen is that the PDF file is downloaded to my local machine and then nothing else happens (helper app not launched nor switched to (if already running) and no attempt to load document). Mozilla doesn't give any feedback for why it isn't loading. Is this bug only for a bad path/app? Does it work if you specify a valid path (and have enough memory, etc.)?

I've only seen this bug if I specify a nonexistent application, or don't specify a full path to the application (Bug #56662). But the behavior you're describing is identical to what I saw. Maybe you need to specify the full, Mac-style, colon-seperated path to the app for it to work?...

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

nav triage team: Should fix this for beta1, marking nsbeta1, mozilla0.9, reassigning to pchen

We're past time to cut these low priority bugs from mozilla0.8. Please update these bugs today.

The best place for the fix that I can find is in http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperApp Service.cpp#847. The call to OpenWithApplication() is where we fail. The fix would be to put up an alert here and ask for the new save location. Kathy's problem is completely different, there the (tm) character in "Acrobat(tm) Reader 4.0" is causing problems because it's not encoded correctly (or I guess more carefully worded, not properly unencoded back to mac charset). Thus it "fails" to find the app. Sigh.

Changing target milestone to mozilla0.9, marking 58228 nsbeta1-

Suggested UI (tweaked from 4.x): +--------------------------------------------------------------+ |::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| +--------------------------------------------------------------+ | . The document "HIGuidelines.pdf" was downloaded, but | | /!\ could not be opened with the application "Acrobat™ | | """ Reader 4.0" because the application could not be found. | | If you save the document, you may be able to open it | | manually. | | | | What do you want to do with "HIGuidelines.pdf"? | | | | ( Choose Application ... ) ( Delete ) (( Save ... )) | +--------------------------------------------------------------+ Insert explanation as appropriate: * the application could not be found * the application quit with an error * an unknown error of type {errorNum} occurred Luckily, the suggested solution applies to any of those explanations.

Wow, that is absolutely the coolest ASCII rendering of an alert dialog box I have ever seen! :)

Since this is already minused, resetting target milestone to get off 0.9 radar

Marking nsbeat1+, mozilla0.9.1

as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from mozilla0.9.1 to mozilla0.9.2.

nav triage team: Pushing out to mozilla0.9.3

*** Bug 84270 has been marked as a duplicate of this bug. ***

nav triage team: Pushing out to mozilla1.0. It wouldn't be very hard to put up a dialog saying we couldn't find the associated helper app, but it would take quite a bit of work to choose a new helper app or allow the user to select where to save the file.

> It wouldn't be very hard to put up a dialog saying we couldn't find > the associated helper app, but it would take quite a bit of work to > choose a new helper app or allow the user to select where to save the > file. Can I suggest actually implementing this simple dialog for now anyway? It will help people by letting them know what happened and it will provide a starting point for future more advanced implementation.

Having similar problem with 0.9.3 (also 0.9.1) on linux. However paths are correct to application(s). Could not get pdf or ps files to display with acroread or ghostscript respectively. Files would download to /tmp but app never ran. Stumbled across this old posting, which required playing games with the "Ask me before downloading" checkbox, which seemed to fix my problem: http://csf.colorado.edu/archive/2000/mozilla-unix/msg01930.html Now I can see pdf and ps files, but still have two other problems: 1. When viewing ps files, it *always* asks before downloading the file, even when I tell it not to (this is mentioned in another bug report). However, for pdf files, it does not ask after I told it not to ask. Perhaps this is just random. 2. The pdf and/or ps files are not deleted from the /tmp directory after the acroread or ghostscript applications exit. (Maybe they are deleted after mozilla exits -- I have not tried that -- I will when I shut down mozilla.)

The first problem is known as bug 48948, the second - as bug 63105 (and it was fixed by making sure Mozilla deletes files on exit). BTW, the best way to see if your helper app problem is already reported is by going through the dependedcy list of bug 78106.

->law

->099

I put in code in nsExternalHelperAppService.cpp to check for error on the ::Launch call (part of bug 27609) but it seems that the code that actually issues the request doesn't detect the error (or doesn't pass back an error code). This will require more work.

nsbeta1- per ADT triage team

I believe this was fixed in bug 162249.

Actually, fixed in bug 27609 and perfected in bug 162249.

*** This bug has been marked as a duplicate of 162249 ***