Closed Bug 56662 Opened 24 years ago Closed 13 years ago

Cannot load helper apps unless app has full path

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 397700

People

(Reporter: stephe, Unassigned)

References

Details

(Keywords: helpwanted)

Attachments

(1 obsolete file)

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.
reassign :mscott
Assignee: av → mscott
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?
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.
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Moving to preferences component.
Component: Plug-ins → Preferences
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.
This used to work correctly with Netscape 4 => 4xp keyword
Keywords: 4xp
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".
Blocks: 52441
Blocks: 78106
Depends on: 78919
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
*** Bug 84269 has been marked as a duplicate of this bug. ***
*** Bug 85477 has been marked as a duplicate of this bug. ***
*** 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
*** Bug 129937 has been marked as a duplicate of this bug. ***
*** Bug 129720 has been marked as a duplicate of this bug. ***
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
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.
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. ***
Attached patch patch (obsolete) — — Splinter Review
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?
> ... 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
> ... 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+
Attachment #131602 - Flags: superreview?(tor)
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
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 → ---
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).
I wholeheartedly agree with Nicolas!! Fix this bug in FireFox too!
*** Bug 302883 has been marked as a duplicate of this bug. ***
(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...
Some discussion as to ways to fix this under linux are coming up at: https://bugs.launchpad.net/firefox/+bug/18995
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.
> 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.
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
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
Closed: 13 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: