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.

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.

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.

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.

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).

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

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?

mass reassigning to nobody.

btw: I added a note on this on https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIProcess#init()

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.

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>