Last Comment Bug 307463 - nsProcess::init fails for Mac OS X application bundles (foo.app)
: nsProcess::init fails for Mac OS X application bundles (foo.app)
Status: NEW
:
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: 1.8 Branch
: PowerPC Mac OS X
: -- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks: 172817 339893
  Show dependency treegraph
 
Reported: 2005-09-07 23:44 PDT by Jesse Ruderman
Modified: 2015-06-25 23:41 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
possible fix v1.0 (5.29 KB, patch)
2005-09-08 11:19 PDT, Josh Aas
no flags Details | Diff | Splinter Review

Description Jesse Ruderman 2005-09-07 23:44:56 PDT
nsProcess::init fails for Mac OS X application bundles.  To use nsProcess to run
a Mac OS X application, I have to dig inside the .app and find the executable
myself.
Comment 1 Josh Aas 2005-09-08 11:19:53 PDT
Created attachment 195296 [details] [diff] [review]
possible fix v1.0

This would probably work. It compiles, but I haven't tested it myself. I'll
leave it up to others to request review if they want once it has been tested.
Comment 2 Simon Fraser 2005-09-08 11:31:27 PDT
I think we'd want to use Launch Services rather than the old LaunchApplication()
-- LSOpenFSRef(), LSOpenCFURLRef() or LSOpenApplication().

A question I have is which kind of apps nsIProcess should be able to open --
should it inlude command-line tools (/usr/bin/ls) for example?
Comment 3 Benjamin Smedberg [:bsmedberg] 2005-09-08 11:35:27 PDT
nsIProcess should absolutely be able to open command-line tools. I would argue
really that bundle-launching is out of scope for nsIProcess, but if it can be
added without sacrificing direct executables then I suppose it wouldn't hurt.
Comment 4 Josh Aas 2005-09-08 13:14:24 PDT
For the record, I wasn't out to rewrite the whole thing. I don't really have
time to do that correctly right now. I just wanted to fix this bug.
Comment 5 Phil Ringnalda (:philor) 2006-04-25 20:32:53 PDT
A branch-safe fix before Firefox 2.0 would be nice: using bug 172817's external editor for view-source fails here for Foo.app (and in bug 322865 for Foo.app/Contents/MacOS/foo).
Comment 6 Stan Shebs 2006-12-05 12:58:28 PST
This bug is a problem for dafizilla, see http://dafizilla.sourceforge.net/viewsourcewith/faq-macosx.php
 for their faq on the bug.
Comment 7 Christian Höltje 2007-04-05 17:28:19 PDT
Any progress on this?  If not, can someone who knows what's going on explain the problem in developer.mozilla.org so that other developers don't fall into this problem too?
Comment 8 Doug Turner (:dougt) 2007-10-08 16:19:44 PDT
mass reassigning to nobody.
Comment 9 Frank Wein [:mcsmurf] 2010-04-08 02:57:12 PDT
btw: I added a note on this on https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIProcess#init()
Comment 10 Christian Höltje 2010-12-07 19:52:19 PST
Thanks Frank Wein.

Unfortunately in FF4beta, nsIFilePicker's filterApps now handles OS-X applications sort-of-correctly now (it won't let you pick files that have the executable bit set -- it only lets you pick .app applications).  So now this is doubly annoying.

Under OS-X you cannot let a user pick an application and then run it with arguments. 

So basically, we've gone backwards -- I will have to screw over all my Mac users and require that they specify the application by typing in the path....and I'll have to figure out a way to execute an .app application.

 -- call me annoyed.
Comment 11 Christian Höltje 2010-12-07 20:25:17 PST
I opened a bug for nsIFilePicker.filterApps not handling non-app-bundles: bug 617515.

I'm essentially doing this to work around this bug:

/usr/bin/open -a <app-bundle> --args <arguments>

Note You need to log in before you can comment on or make changes to this bug.