+++ This bug was initially created as a clone of Bug #863092 +++ This is useful if you are working command-line handler code (as I was recently) or if you just want a command-line way to open a new link in your existing process.

Comment on attachment 739579 [details] [diff] [review] patch Review of attachment 739579 [details] [diff] [review]: ----------------------------------------------------------------- Kinda wish we didn't have to use +remote here. But, that train has left the station.

Can you please change this option to say "Do not pass any arguments by default"? That is a more scalable solution than coming up with one of these hacks every time. :-)

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #2) > Can you please change this option to say "Do not pass any arguments by > default"? That is a more scalable solution than coming up with one of these > hacks every time. :-) I thought of that, but I'm kind of hoping we can avoid adding more default arguments, and instead work on ensuring sensible behavior for all command-line users (including non-mach users) without passing arguments every time. Semi-related: An alternate way to solve this bug would be adding a "-remote" options to nsAppRunner which could override an earlier "-no-remote". Then "mach run -remote" would do the right thing without any changes to mach itself. I'll explore that approach before landing this patch.

I thought that we already have a -remote option?

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #4) > I thought that we already have a -remote option? Oops, we do, and it's Linux-only and means something slightly different (it's to specify an X11 desktop, or something). I'm not sure if it would be possible to overload it in a compatible way or if we'd need some different name. If we do need a different name, I can't think of any non-horrible ones. :/

(In reply to comment #5) > (In reply to :Ehsan Akhgari (needinfo? me!) from comment #4) > > I thought that we already have a -remote option? > > Oops, we do, and it's Linux-only and means something slightly different (it's > to specify an X11 desktop, or something). I'm not sure if it would be possible > to overload it in a compatible way or if we'd need some different name. If we > do need a different name, I can't think of any non-horrible ones. :/ Yeah, sorry, what I meant was, "remote" is already taken. And it obviously doesn't do what you would expect it to, it's a Gecko command line option after all. :P

So, the alternatives to this all had issues of their own that I wasn't able to find great solutions for (e.g. comment 3, comment 4) so I'm going with my original patch for now because it's the simplest fix for my own use cases: https://hg.mozilla.org/integration/mozilla-inbound/rev/5b37e8c3c0bf