Cannot load helper apps unless app has full path

RESOLVED DUPLICATE of bug 397700

Status

RESOLVED DUPLICATE of bug 397700
19 years ago
3 years ago

People

(Reporter: stephe, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

19 years ago
When using "Preferences/Helper Applications" to add helper apps, Mozilla cannot
launch the app unless the full path of the app is used even though the app's dir
is on PATH.  For instance, I have to use /usr/bin/xmms rather than just xmms
even though /usr/bin is on PATH.  This behavior is most non-intuitive.

Tested with Mozilla 101406 on Linux.

Comment 1

19 years ago
reassign :mscott
Assignee: av → mscott

Comment 2

19 years ago
That's odd. I actually only have the helper app name for my helper apps (xmms,
xtarr) and they work for me. I'm running Redhat 6.1. How about you?
(Reporter)

Comment 3

19 years ago
Redhat 6.2
I am also seeing this (RedHat 6.2, mozilla trunk build 2000110608)
*** Bug 57868 has been marked as a duplicate of this bug. ***
Added self to CC.
I'm seeing this on RH 6.2, CVS 11/6/2000.

Comment 7

19 years ago
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 8

18 years ago
I confirm this still happens on Mozilla 0.7 on RHL 7.0.  Mozilla is started from
a shell which has everything in $PATH.  
Same situation as Alan, but I run Red Hat 6.1. Also happens with Mandrake 7.1

Comment 10

18 years ago
Moving to preferences component.
Component: Plug-ins → Preferences

Comment 11

18 years ago
If instead of calling the helper application directly, we do 

sh -c "helper_app tmpfile; rm -f tmpfile" 

or something similar, it will solve this bug, bug #76092, bug #57420,
potentially - bug #58667, and also allow people to use shell syntax in the
helper app
specification.

Comment 12

18 years ago
This used to work correctly with Netscape 4 => 4xp keyword
Keywords: 4xp

Comment 13

18 years ago
i was thinking
sh -c "helper_app tmpfile && rm -f tmpfile" 
and i'm told, that you can do sh -c "helper_app tmpfile | outpoint && rm -f 
tmpfile".

Updated

18 years ago
Blocks: 52441
Blocks: 78106
A correct implementation of mailcap stuff sorta _has_ to use something like 'sh
-c'.  But "application" is actually allowed to be an arbitrary shell command;
all we should be doing is some argument replacement.

The current architecture does not support this -- hence the dependency on bug
78919

Comment 15

18 years ago
*** Bug 84269 has been marked as a duplicate of this bug. ***

Comment 16

18 years ago
*** Bug 85477 has been marked as a duplicate of this bug. ***

Comment 17

18 years ago
*** Bug 86628 has been marked as a duplicate of this bug. ***
*** Bug 94000 has been marked as a duplicate of this bug. ***
QA Contact: shrir → sairuh
Component: Preferences → File Handling

Comment 19

17 years ago
*** Bug 129937 has been marked as a duplicate of this bug. ***

Comment 20

17 years ago
*** Bug 129720 has been marked as a duplicate of this bug. ***

Comment 21

17 years ago
I have been seeing the same problem using my PowerbookG3 MacOS9.x.
However, I have not seen Mac users complain this problem.
Does it something to do with more than one partition in my system HD?
QA Contact: sairuh → petersen

Comment 22

16 years ago
I think it worked fine on Mozilla 1.2.1, but when I started to use the newly
released 1.3, the problem appears again.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
It couldn't possibly have worked in 1.2.1...  None of this code really changed
since then.

Comment 24

16 years ago
I just tried this on Mozilla 1.2.1 and 1.3.

1.2.1 does not require the full path to the application, 1.3 does.

Also the dialog box that appears when you click on an unknown file is totally
different in 1.3 vs 1.2.1, so I think this code did change significantly.

Also it appears that 1.3 cannot handle pdf email attachments if the mime type is
application/octet-stream.  1.2.1 handles them fine.
There was indeed a major UI revamp between 1.2 and 1.3.  So the dialog box is
different. None of the back end is different, however.  And that's what would
have to handle non-full-path filenames...  I'm curious how you got them to
"work" in 1.2.1.
*** Bug 217116 has been marked as a duplicate of this bug. ***
The steps from comment 0 work for me. I added a type foo/bar with an application
"gvim", and used a php script to generate foo/bar content. It worked just fine
and mozilla opened the file in gvim, as I expected. This is with a cvs build
from yesterday or so, on linux.

On the other hand, the helper app dialog (The Open/Save dialog when loading
unhandled content) does not allow you to enter files w/o a path. Is this what
the bug is about?
This bug is about being able to give just executable names anywhere where we 
need to type in a path.
ok, this could probably be done by moving GetFileTokenForPath onto
nsIExternalHelperAppService and calling that from the helper app dialog on the
user-entered path... and if that suceeds, set it as the preferredApplication on
the mime info.

taking...
Assignee: mscott → cbiesinger
*** Bug 219125 has been marked as a duplicate of this bug. ***
Created attachment 131602 [details] [diff] [review]
patch

Allows entering files in $PATH in the helper app dialog
oh damn, just noticed that I do a createInstance in this bug...
I'll change it to getService
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.6alpha
This function should live on some other interface, in my opinion.  Most likely,
an interface in xpcom somewhere.
getFileTokenForPath?  how is this any different that creating a nsIFile and
init'ing it?  
dougt: The function is probably poorly named... The difference is that
getFileTokenForPath also searches $PATH for the file, e.g. if it gets passed
"gvim", it may return an nsIFile that has a path of "/usr/bin/gvim"
I do not agree with this solution.  why did it "work" in 1.2.1?

Comment 37

16 years ago
> ... if it gets passed
> "gvim", it may return an nsIFile that has a path of "/usr/bin/gvim"

Does this mean that if I change my PATH so /usr/local/bin/gvim is before
/usr/bin/gvim, and restart mozilla, mozilla will continue to use /usr/bin/gvim?
> I do not agree with this solution.  why did it "work" in 1.2.1?

1.2.1 didn't offer a textfield for the application, it only had a filepicker


>Does this mean that if I change my PATH so /usr/local/bin/gvim is before
>/usr/bin/gvim, and restart mozilla, mozilla will continue to use /usr/bin/gvim?

It was an EXAMPLE.

(However, the file will get searched in the path by the time you enter it, and
the absolute path will be stored. so moz will continue to use /usr/bin/gvim)

If we want things to happily update when PATH is changed, all we need to do is
to fix bug 78919... ;)
hmm, bug 78919 is mostly about the _default_ application handler, not what the
user enters... I didn't really intend to change anything about
preferredApplicationHandler, at least not in that bug

Comment 41

16 years ago
> ... moz will continue to use /usr/bin/gvim

This is actually the bug as I saw it.  I want mozilla to use PATH-resolution
whenever a helper app is executed, that is why I did not want to enter a full
path to the helper app in the first place.  I'll go and vote for 78919 now. :-)
Comment on attachment 131602 [details] [diff] [review]
patch

r=me on the general code, but I'd still like to see this on some other
interface instead....

And perhaps we should make use of bug 78919 more and make it possible to store
non-absolute paths in mimeTypes.rdf?
Attachment #131602 - Flags: review?(bzbarsky) → review+

Updated

15 years ago
Attachment #131602 - Flags: superreview?(tor)

Comment 43

15 years ago
Comment on attachment 131602 [details] [diff] [review]
patch

Removing sr per conversation with biesi (waiting for 78919).
Attachment #131602 - Flags: superreview?(tor)
ok, doing this "the right way" will require interface changes to nsIMIMEInfo, to
allow setting and probably also getting a string for the helper app instead of
an nsIFile.
Status: ASSIGNED → NEW

Comment 45

15 years ago
I think this was fixed some time ago?

At least, in 1.7, I can just type "xmms" into the helper app prefs dialog
without having to use a fully-qualified pathname.
At the moment it resolves to the fully qualified name when you type it in...
ideally we would resolve when we're about to run the program.  We could spin
that off into a separate bug, though.
Comment on attachment 131602 [details] [diff] [review]
patch

marking patch obsolete per comment 44
Attachment #131602 - Attachment is obsolete: true
unfortunately, I probably won't get to fixing this anytime soon... -> default
owner, helpwanted
Assignee: cbiesinger → file-handling
Keywords: helpwanted
OS: Linux → All
Priority: P3 → --
QA Contact: chrispetersen → ian
Hardware: PC → All
Target Milestone: mozilla1.6alpha → ---

Comment 49

14 years ago
I believe that the helper application dialog should not be a file picker at all,
but rather a brand new dialog box that lists all the files in $PATH directories
and has a typing area to allow entering a command line by hand (and maybe a
button "look elsewhere" to invoke a reah file picker).

Comment 50

14 years ago
I wholeheartedly agree with Nicolas!!

Fix this bug in FireFox too!
*** Bug 302883 has been marked as a duplicate of this bug. ***

Comment 52

13 years ago
(In reply to comment #49)
> I believe that the helper application dialog should not be a file picker at
> all,
> but rather a brand new dialog box that lists all the files in $PATH directories
> and has a typing area to allow entering a command line by hand (and maybe a
> button "look elsewhere" to invoke a reah file picker).
> 

Exactly.  While we're at it, please let us specify parameters to the app as well.
All the "me too"-ers should note the "helpwanted" keyword.  If you care so much about this, fix it.
and please use one bug per issue...

Comment 55

10 years ago
Some discussion as to ways to fix this under linux are coming up at: https://bugs.launchpad.net/firefox/+bug/18995

Comment 56

10 years ago
There is a proposed patch for this in the https://bugs.launchpad.net/firefox/+bug/18995 - apparently it is meeting some resistance.

I'd strongly urge those in charge of the Mozilla codebase to consider this fix. The default behaviour on Linux now is effectively a poke in the eyes for people not familiar with Linux file system conventions. 

I've gotten my own problem fixed but an unfixedbug that e.g. makes it impossible to download and view PDF docsuments in 2009 is a real obstacle to user takeup on Linux.

Comment 57

10 years ago
> apparently it is meeting some
> resistance.

It is not resistance to the change, but rather the *buntu devs don't want to make the change themselves, they prefer it happen upstream.

Comment 58

10 years ago
OK. As a non-expert it seems to make sense to incorporating the patch (which seems already to have been developed in https://bugs.launchpad.net/firefox/+bug/18995 into Mozilla).  

I have no insight into how you allocate work and/or discuss amongst yourselves but again from the outside it seems a bit sad that a known usability wart on Linux in a feature that works very well on Windows for one reason or another goes unadressed for a looong time.  Had this bug been a child it would have started school now. 

Anyway - good luck, happy hacking.
Assignee: file-handling → nobody
QA Contact: ian → file-handling

Comment 59

7 years ago
Marking as duplicate of this newer bug because it has more recent discussions and also a suggested solution using the GTK3 api rather than implementing something custom in firefox.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 397700
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.