Open Bug 57420 Opened 20 years ago Updated 1 year ago

no support for helper app command line args

Categories

(Firefox :: File Handling, defect)

defect
Not set
normal

Tracking

()

People

(Reporter: sballard, Unassigned)

References

(Depends on 1 open bug, Blocks 4 open bugs)

Details

(Keywords: helpwanted, Whiteboard: [proto])

(Using M18 on Linux (buildid 2000101805) but I would guess this is XP)

It is impossible to set a commandline argument to a helper application. For
example, the linux mp3 player xmms takes a "-e" argument to "enqueue" the
argument (add it to an already playing playlist) versus playing it immediately
(replacing the current playlist). With Mozilla, it is impossible to configure
xmms as a helper application with this flag enabled.

Steps to reproduce:
Click on a link that returns an unknown content-type (eg audio/mpegurl)
Attempt to enter "/usr/X11R6/bin/xmms -e" as the command

Expected results:
Entering this is possible, and runs xmms with the arguments "-e" "tmpfilename"

Actual results:
The text editing box is greyed out; it is only possible to browse to
applications, so the "-e" cannot even be entered.



The same bug manifests itself in a different way in the preferences dialog:

Edit > Preferences > Helper Applications > New
Set an appropriate description and extension, set the mimetype to audio/mpegurl,
and the action to /usr/X11R6/bin/xmms -e
Ok > Ok
Click on a link with this mimetype
Press Ok to open with "xmms -e"

Expected results: xmms is launched with the arguments "-e" "tmpfilename".
Actual results: nothing apparently happens at all

Presumably Moz is actually looking for a file called "xmms -e" in the
/usr/X11R6/bin directory and trying to run it - this is pure speculation, but
makes sense.

A workaround is to create a script eg /home/$user/bin/xmms-e containing the
following:

#!/bin/bash
xmms -e "$@"

Then configure the helper application to be xmms-e.

This is 4xp because all 4.x versions supported arbitrary command lines for
helper apps: You could enter anything you wanted and %s was replaced by the
temporary filename. The lack of such support makes it impossible to configure
mp3s and m3us to enqueue rather than play, for example, when clicked on.

(note: I'm submitting this as UNCONFIRMED because I've only tested on M18, not
the latest nightlies)
over to command-line component.

shrir/mscott, is this a known problem?
Assignee: matt → don
Component: Preferences → XP Apps: Cmd-line Features
From the description of "XP Apps: Cmd-line Features":

For problems with command line parameter handling.
Examples: mozilla -console doesn't work. mozilla -ProfileManager doesn't work.

From that description, I would assume this is to do with the command line of
*mozilla itself*, not just "anything tangentially related to command lines".
This is a bug in the helper app support, not in command line support; every
other helper app bug I could find was in the Preferences component. I'm not 100%
sure that Preferences was right, but I'm pretty sure that "cmd-line features" is
wrong.

(PS: Added 4xp keyword because, as stated in the original description, 4.x
supported this extremely well)
Keywords: 4xp
 I can confirm this problem on a current trunk CVS build: if you give a
program a perfectly valid switch, Mozilla will do ... well, nothing, when
it tries to run that program. No error message, no nothing, just a vast
silence. (Which I think is an error in and of itself.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Could someone take a look at this and decide whether this is the right
component, at least? I remain convinced that "Cmd-line features" is the wrong
place for this bug and will just keep it away from the eyes of the right people
to solve it.

If there are no objections, I might actually move it back to "preferences",
where I'm pretty sure it belongs (all other helper app bugs I can find are there).
mscott or law seem to be the appropriate candidates to own this bug.  Adding law
to the CC.

Can one of you fess up or find another owner?
accepting
Assignee: don → mscott
[--> Preferences]
Component: XP Apps: Cmd-line Features → Preferences
*** Bug 67143 has been marked as a duplicate of this bug. ***
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 #56662,
potentially - bug #58667, and also allow people to use shell syntax in the
helper app
specification.
Not 100% - it's theoretically possible that someone might want to put something
after the tmpfile name in the command. A contrived example would be this (for
someone who wanted to play a sound and then get audible notification that it had
finished:
bplay tmpfile finished.wav

If we're using "sh -c", there are other things that someone might want to do:

zcat tmpfile | tar xvf
cat tmpfile >/dev/audio

etc. Being able to put something *after* the tmpfile name is genuinely useful.

On the other hand, I'd still take the "sh -c" solution proposed here over what
we have now :)
Stuart, I agree. My point was that "sh -c" solution can be implemented in a few
minutes and will be so much better then the current one.
Blocks: 52441
Blocks: 78106
Severity: minor → normal
Keywords: mozilla1.0
Aleksey: you're wrong about sh -c being a "few-minute" fix.  The sh -c solution
requires some rearchitecting of the whole MIMEInfo interface, because the string
in question has to be _stored_ somewhere.  And set.  But not on Windows/Mac,
necessarily. Unless we change a _lot_ of code.  Adding dependency on the bug
that should implement the necessary arch changes.
Depends on: 78919
Component: Preferences → File Handling
Is there any progress on this?
I think the sh -c approach, while it will solve the problem, makes it
easier to untroduce "bad" or "difficult to debug" situations, and esp if
someone else can dink with your helper app preferences, and make you run
random commands, it seems like it could increase the security concerns
slightly.
What's wrong with the NS 4.x way of doing it, where you put a %s in the
string for where the filename goes?  I guess you could just add a ' %s' to
the end if a %s isn't specified, to mirror current behaviour...
Is this being worked on currently?  +1 vote...
If you notice this bug depends on another bug.  That bug is an architectural
problem that needs to be solved for this bug to work....  Suggestions on a good
implementation for bug 78919 are welcome in that bug.  :)
Chris, sh -c *is* the "NS 4.x way of doing it".
Oh.  Well, I don't guess that makes it any more correct...
I think, after looking at bug 78919, that the *right* solution
will be to come up with some sort of more-complicated wrapper
class to be used in the XP layer, and how the internals of that
get used could be left to the arch-specific layer.  Then,
whether we use a string to pass to sh -c, or we tear it apart
and do all the work ourselves, it can be done.  More on that
in 78919...
*** Bug 112469 has been marked as a duplicate of this bug. ***
Since Mozilla is moving toward a 1.0 release, it would be lovely if this bug and
bug #78919 could be resolved, as these bug essentially renders the UNIX version
of this browser nearly useless, save a very small and limited subset of the
functionality expected on the modern WWW.  I have read through all of the
comments between these two bugs, and I see that it is quite a substantial
rework, but in further isolating the UNIX crowd while catering to the win* and
mac* crowd, who already have excellent browsers, it's essentially leaving some
of the most devoted followers behind.  I see the bug was originally submitted
10/18/2000...  1.5 years and no helper applications...  qu'elle domage.
> these bug essentially renders the UNIX version of this browser nearly useless

I strongly disagree! Just install plugger v.4 and you'll never need the helper
app support in Mozilla itself - plugger will launch all of them for you! And
plugger config does allow all kinds of command line arguments.

Of course, this bug still needs to be fixed...
I don't understand how support for the system mailcap and mime.types files were
added without this bug being fixed. Obviously some kind of solution to providing
this functionality exists in mozilla -- why isn't it exposed in the UI?

For advanced users, the obvious workaround is to create your own mailcap or
mime.types files with the helper apps you want, and then set the prefs in your
user.js (see the prefs that start with "helpers." in about:config for the
specific prefs to set).

This should still be fixed, but the support for system mailcap and mime.types
files made it a WHOLE lot less vital - which is probably why it's languished.
This bug is not going to be resolved for 1.0.  Even if I were to write the code
today, it would not be allowed on the branch by drivers, since it would be a
huge change.  

> I don't understand how support for the system mailcap and mime.types files
> were added without this bug being fixed.

Heh.  If you actually try it, you'll see that we just take the appname from the
mailcap file and ignore any command-line args that may be present.  That's bug
83305 and can and will be fixed without fixing this bug or bug 78919, as I just
commented over there.  

Discussion in _this_ bug (which deals with storing switches to commands in
mimeTypes.rdf, if I understand correctly) is pointless until bug 78919 is fixed.
 Complaining isn't going to make it any more likely to be fixed; what's needed
is developer time.  At the moment there are exactly two people working on these
bugs:

Bill Law, who also has to do quicklaunch, windows integration, and has to deal
with the scheduling priorities of his managers (and who's doing excellent work
in bug 86640 that will make at least mailcap files work correctly).

Me. I'm also in school, trying to finish my thesis by May 10, have a job, and
prefer not to spend _all_ my time in front of the computer.

So the best way you can help get this bug resolved is to learn the code and fix
it.  I can provide pointers to the responsible code if someone wants.
Blocks: 142389
*** Bug 156672 has been marked as a duplicate of this bug. ***
Blocks: 18687
*** Bug 160238 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen
*** Bug 176508 has been marked as a duplicate of this bug. ***
*** Bug 177236 has been marked as a duplicate of this bug. ***
*** Bug 184873 has been marked as a duplicate of this bug. ***
*** Bug 214897 has been marked as a duplicate of this bug. ***
There are 8 duplicates in this bug now.
and the point of your comment is...?
Blocks: 61025
Because of the header "Assigned To: Scott MacGregor (gone)
<mscott@formerly-netscape.com.tld>" I am taking this bug and intend to assign it
to Boris or Christian or neither depending on things, in order of importance,
including which of them want it, my guess about who would do it better, and my
secret coin-flip if I am too ambivalent to make a decision.

This bug is the gateway to audio upload, but people see audio upload as a
potential security threat.

This bug is not a security threat.  Audio upload, on a sufficiently robust
browswer and equipment security infrastructure, is also not a security threat.
Status: NEW → ASSIGNED
Well, I didn't get it, but at least Scott did.  Boris and Christian, please
consider this one for your next helper application improvement.
Assignee: mscott → file-handling
Status: ASSIGNED → NEW
QA Contact: chrispetersen → ian
I'm not really actively working on helper application stuff and haven't been for
a long time now...
this is on my list of things to fix, but it's unclear when I can get to it.
patches accepted.
Keywords: helpwanted
Priority: P3 → --
*** Bug 280877 has been marked as a duplicate of this bug. ***
Any chance this bug will get solved? Most annoying have things that worked in
Netscape 4 not working in Mozilla/Firefox.
No longer blocks: 61025
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Duplicate of this bug: 308815
Duplicate of this bug: 406060
As per the comment in bug 406060, we won't be able to hand off mailto: links to Windows mail in Vista if it's not the default app, if we don't get this fixed for Firefox 3.  OTOH, most users who use Windows Mail in Vista are likely to have it set as the default mailto: app.  Nominating...
Assignee: nobody → jmathies
Blocks: 393122
Flags: blocking1.9?
OS: Linux → All
Hardware: PC → All
Whiteboard: [proto]
-'ing as this is not a regression.
Flags: blocking1.9? → blocking1.9-
Depends on: 400852
Assignee: jmathies → nobody
Blocks: 504123
Duplicate of this bug: 525506
Does not depend on 400852.

All your musings about what Firefox should do are void.  The correct behaviour is described in RFC 1524 (Appendix A).
(In reply to Chris P. Ross from comment #13)
> Is there any progress on this?
> I think the sh -c approach, while it will solve the problem, makes it
> easier to untroduce "bad" or "difficult to debug" situations, and esp if
> someone else can dink with your helper app preferences, and make you run
> random commands, it seems like it could increase the security concerns
> slightly.

OTOH, the mailcap file may contain commands that do the wrong thing when invoked the Firefox way, and it will be our fault if they do.  For example, tar expects argument 1 to contain options, so the file path is treated as options.  This particular case is rather harmless but it is easy to construct one that is dangerous.
If you are concerned about shell security, you can invoke { metamail -b -c $type $path; }; that way, if anything happens, metamail will be to blame.  This will also make Firefox ignore the preferences entry, unless you use it to set $MAILCAPS first.  Or maybe having the preferences entry is bad for security and the default path should always be used.
This used to depend on bug 78919, which probably was the original reason why the current Firefox way is so limited.

I agree with comment 13 that invoking the shell is too dangerous. But it's not necessary either to fix this bug.

RFC 1524 A states e.g.:
"The two characters "%s", if used, will be replaced by the name of a file for the actual mail body data."
and ditto for other parameters. This should be easy enough to do in our code. We just need to take care that we quote the argument properly.

This bug is marked helpwanted. Any takers? I.e. developers who want to give this a try?
Product: Core → Firefox
Version: Trunk → unspecified
See Also: → 1541780
You need to log in before you can comment on or make changes to this bug.