58667 - Mozilla is silent if a helper app doesn't start

Status: RESOLVED DUPLICATE of bug 162249

(Core Graveyard :: File Handling, defect)

Description

[Chris Siebenmann]

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.

Comment 1

[Arjen Hommersom]

confirmed on build 2000110706, linux/Mandrake 7.2.

Comment 2

[Scott Gifford (old account)]

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.

Comment 3

[Kathleen :Brade]

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.)?

Comment 4

[Scott Gifford (old account)]

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?...

Comment 5

[Viswanath Ramachandran]

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

Comment 6

[Paul Chen]

nav triage team:

Should fix this for beta1, marking nsbeta1, mozilla0.9, reassigning to pchen

Comment 7

[selmer (gone)]

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

Comment 8

[Paul Chen]

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.

Comment 9

[Paul Chen]

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

Comment 10

[Matthew T (active 1999-2002)]

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.

Comment 11

[Scott Gifford (old account)]

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

Comment 12

[Paul Chen]

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

Comment 13

[Paul Chen]

Marking nsbeat1+, mozilla0.9.1

Comment 14

[Viswanath Ramachandran]

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

Comment 15

[Paul Chen]

nav triage team:

Pushing out to mozilla0.9.3

Comment 16

[R.K.Aa.]

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

Comment 17

[Paul Chen]

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.

Comment 18

[Aleksey Nogin]

> 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.

Comment 19

[gene smith]

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.)

Comment 20

[Aleksey Nogin]

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.

Comment 21

[Paul Chen]

->law

Comment 22

[Peter Trudelle]

->099

Comment 23

[Bill Law]

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.

Comment 24

[Peter Trudelle]

nsbeta1- per ADT triage team

Comment 25

[:Gavin Sharp [email: [e-mail]]]

I believe this was fixed in bug 162249.

Comment 26

[:Gavin Sharp [email: [e-mail]]]

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

Comment 27

[Boris Zbarsky [:bzbarsky]]

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