Open
Bug 57420
Opened 24 years ago
Updated 2 years ago
no support for helper app command line args
Categories
(Firefox :: File Handling, defect)
Firefox
File Handling
Tracking
()
NEW
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)
Comment 1•24 years ago
|
||
over to command-line component. shrir/mscott, is this a known problem?
Assignee: matt → don
Component: Preferences → XP Apps: Cmd-line Features
Reporter | ||
Comment 2•24 years ago
|
||
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
Comment 3•24 years ago
|
||
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
Reporter | ||
Comment 4•24 years ago
|
||
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).
Comment 5•24 years ago
|
||
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?
Comment 9•24 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 #56662, potentially - bug #58667, and also allow people to use shell syntax in the helper app specification.
Reporter | ||
Comment 10•24 years ago
|
||
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 :)
Comment 11•24 years ago
|
||
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.
Updated•24 years ago
|
Severity: minor → normal
Keywords: mozilla1.0
Comment 12•24 years ago
|
||
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.
Updated•23 years ago
|
Component: Preferences → File Handling
Comment 13•23 years ago
|
||
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...
Comment 14•23 years ago
|
||
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. :)
Comment 16•23 years ago
|
||
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...
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
> 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...
Reporter | ||
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
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.
Updated•22 years ago
|
QA Contact: sairuh → petersen
Updated•22 years ago
|
Blocks: input-helper-apps
Comment 30•20 years ago
|
||
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
Comment 31•20 years ago
|
||
Well, I didn't get it, but at least Scott did. Boris and Christian, please consider this one for your next helper application improvement.
Updated•20 years ago
|
Assignee: mscott → file-handling
Status: ASSIGNED → NEW
QA Contact: chrispetersen → ian
Comment 32•20 years ago
|
||
I'm not really actively working on helper application stuff and haven't been for a long time now...
Comment 33•20 years ago
|
||
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 → --
Comment 35•20 years ago
|
||
Any chance this bug will get solved? Most annoying have things that worked in Netscape 4 not working in Mozilla/Firefox.
Updated•17 years ago
|
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Comment 39•17 years ago
|
||
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...
Updated•17 years ago
|
Whiteboard: [proto]
Updated•16 years ago
|
Assignee: jmathies → nobody
Comment 42•11 years ago
|
||
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).
Comment 43•11 years ago
|
||
(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.
Comment 44•11 years ago
|
||
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.
Comment 45•11 years ago
|
||
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?
Updated•8 years ago
|
Product: Core → Firefox
Version: Trunk → unspecified
Updated•6 years ago
|
Updated•2 years ago
|
Severity: normal → S3
Comment 46•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 12 duplicates and 27 votes.
:Gijs, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(gijskruitbosch+bugs)
Comment 47•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(gijskruitbosch+bugs)
You need to log in
before you can comment on or make changes to this bug.
Description
•