nsProcess::init fails for Mac OS X application bundles (foo.app)




12 years ago
2 years ago


(Reporter: Jesse Ruderman, Unassigned)


1.8 Branch
Mac OS X
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



12 years ago
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

Comment 1

12 years ago
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

12 years ago
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?
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

12 years ago
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.
Blocks: 172817
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).
Blocks: 339893

Comment 6

11 years ago
This bug is a problem for dafizilla, see http://dafizilla.sourceforge.net/viewsourcewith/faq-macosx.php
 for their faq on the bug.

Comment 7

10 years ago
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

10 years ago
mass reassigning to nobody.
Assignee: dougt → nobody
btw: I added a note on this on https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIProcess#init()

Comment 10

7 years ago
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

7 years ago
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>
You need to log in before you can comment on or make changes to this bug.