Bug 650078 changed the -no-remote flag's behavior in a surprising, backward incompatible way. Before, it just meant "start a new instance." Now, it also means "don't listen for remote commands." The original behavior wasn't ideal for some users, as described in bug 650078, but others depended on it. For example, I start multiple instances with separate profiles with -no-remote -profile ..., and then use -profile X -new-tab (or -new-window, etc) to open URLs in a specific profile's instance. This change broke that use case, among others. Apart from reverting the change, one simple fix could be to add a -new-instance flag, and have -no-remote just mean "don't listen for remote commands." That would change -new-remote's behavior again, but since it already happened once, I'm guessing that's ok. Alternatively, we could leave -no-remote as is and just add -new-instance. Mozilla people, would you accept a patch that does this? Thanks in advance...
[crickets] when i have free time (which may not be soon :P), i'll plan to whip up a patch for this. feedback is still welcome!
As I reported in 716361, this is also needed for me. I normally use a lot the -remote 'OpenUrl(about:blank)' for I use more than two different firefox profile on my desktop (one for web dev with firebug, one for other url, sometimes to test application with different users). I have two launcher to open new window of each instance with firefox -P myprofile -remote 'OpenUrl(about:blank)'
Here, have a patch. I threw this together in a few minutes of actual editing (ignoring the hours it took me to root-cause the mysterious failure of -remote and find this PR), so approach with caution. I had -no-remote imply -new-instance, since it looks like people want it to mean that all remoting is disabled. I did not have the combination of -no-remote or -new-instance with -remote cause an error; it arguably should, but I don't know if that'd be considered out of scope for this PR. There is one "bonus fix", which is that I tried to correct -no-remote's existing error messages, which looks to have been a victim of copy-and-paste. Testing done: verified that no-remote continues to not listen, that -new-instance does what it says, and that multiple concurrent profiles can be independently targeted with -P -remote. All ad-hoc, so I may have missed something.
Comment on attachment 590139 [details] [diff] [review] Create a -new-instance flag for the functionality of the old -no-remote flag. Thanks for the patch, Jed! Let's see what Benjamin thinks of this.
Attachment #590139 - Flags: review?(benjamin)
Assignee: nobody → jld
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
agreed, awesome, thank you jed! I'll try the patch too. looking forward to seeing it in a release!
I am traveling this week and won't get a chance to look at this until Friday. I will note that I'm hesitant to take this without tests, but I don't think we have any testsuite which can be used to easily test these flags... :-(
Comment on attachment 590139 [details] [diff] [review] Create a -new-instance flag for the functionality of the old -no-remote flag. Yeah, I think this is safe-enough.
Attachment #590139 - Flags: review?(benjamin) → review+
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/dce4363cb7ce Thanks for the patch Jed! (It will be present in the next Nightly) Join us on irc (#developers on irc.mozilla.org) and we'll find some other things for you to work on if you are interested? :-D
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Comment on attachment 590139 [details] [diff] [review] Create a -new-instance flag for the functionality of the old -no-remote flag. >- " -no-remote Open new instance, not a new window in running instance.\n" >+ " -no-remote Do not accept or send remote commands; implies -new-instance.\n" >+ " -new-instance Open new instance, not a new window in running instance.\n" Shouldn't this be #ifdef because it doesn't affect Windows or Mac?
https://developer.mozilla.org/en/Command_Line_Options should be also updated/clarified to reflect bug 650078 and this bug.
I've been reading through this recent patch as well as related bug reports https://bugzilla.mozilla.org/show_bug.cgi?id=684973 and https://bugzilla.mozilla.org/show_bug.cgi?id=684973 and I am trying to figure out whether this -no-remote and -new-instance issue is related to or can help with a problem I've run into. My situation (Linux) is that I am ssh'ing from my local machine X into a remote machine Y where I am debugging a TCL/TK script that displays several things in different tabs of a firefox browser (.html files reside on machine Y). If I have a local firefox running on X, and I just do "firefox bla1.html" on Y it will, of course, use my local firefox to try and open bla1.html and it fails. I just tried a nightly build (i686 from yesterday -- Feb.21, 2011) to try both -no-remote and -new-instance. For the first "firefox -no-remote bla1.html" (-new-instance has same behaviour) all is well. But if I want to then open "bla2.html" in a -new-tab there doesn't seem to be any way to get it to work. Subsequent -no-remote or -new-instance flags on the command-line gives me the "firefox is already running" message. Leaving -no-remote and/or -new-instance off reverts to trying to use the original firefox I had running on machine X. Only luck I've had is by spawning firefox with -no-remote using different profiles each time, but that is extremely cumbersome (starts new browser windows instead of new tabs obviously). Apologies if this is going too far off topic for this thread, but since this is an area that has been worked on recently I thought this would be a good place to start!
hi edward! sounds like you're on the right track. if you start the machine Y firefox with -new-instance, then use firefox -P [Y_PROFILE] (still on machine Y), i think that should open a tab in the machine Y firefox.
Thanks Ryan - I just tried this explicitly and it still seems to try to launch the tab in my original browser on machine X. Here is precisely what I've done (using nightly build from 2 days ago on machine Y): (on machine X -- I should point out that *this* machine is running a much older firefox) 1. firefox & 2. ssh -X Y 3. firefox -new-instance -P screener epic_png.html & first time step #3 launches profile manager in firefox on machine Y. I create the profile "screener" and select it. Subsequent invocations seems to go straight into the profile (I haven't really used profiles before, maybe I've just made a simple mistake that you can point out!) 4. firefox -new-tab -P screener rgs_png.html & Once again, it tries to open rgs_png.html in a tab back on the first instance of firefox on machine X and fails.
hmm. i don't have much experience with running firefox on a remote X display, or using firefox's remote over remote X, but i think the steps you described should work. mind trying something else? what if you create a (differently) named profile on machine X, then start X's firefox with -P [name], like you're already doing on Y?
OK, I did this test and I think we've found a real problem. Here are the steps I followed (machine X to start) 1. firefox -P local & [I create the profile "local" and select it in profile manager] 2. ssh -X Y 3. firefox -new-instance -P screener epic_png.html & 4. firefox -new-tab -P screener rgs_png.html & Again, it goes back to the firefox on machine X running profile "local" that is clearly different to the one requested. Sounds like a real bug in the management of profiles over remotes...
agreed. if firefox remote is supposed to work over remote X displays, and handle all these cases, that sounds like a problem. mind opening a new bug and copying over the discussion here?
My understanding of Jed's fix is that it replicates the old -no-remote behaviour. I use multiple profiles and open links in a new tab in a profile of my choosing. If a browser instance for this profile is already running, I connect to it, if not I start it with the url. My script: firefox -P $PROFILE -remote "ping()" if [ ! $? == 0 ]; then firefox -P $PROFILE -no-remote $URL else firefox -P $PROFILE -remote "openurl($URL,new-tab)" fi I downloaded Firefox 12.0 assuming that it had the -new-instance feature. I created two profiles "ff1" and "ff2", then execute the following on the commandline: 1) firefox -P ff1 -new-instance 2) firefox -P ff2 -new-instance The second command opens a new window for the first profile. It does not start a new instance. I only have one firefox process running afterwards. I don't seem to be able to start two instances (for two different profiles) which both listen for remote connections. Where am I going wrong?
are you sure -new-instance made it into ff 12? i don't see it in -help: heaven:~/src> firefox -v Mozilla Firefox 12.0 heaven:~/src> firefox -help Usage: firefox [ options ... ] [URL] where options include: X11 options --display=DISPLAY X display to use --sync Make X calls synchronous --g-fatal-warnings Make all warnings fatal Firefox options -h or -help Print this message. -v or -version Print Firefox version. -P <profile> Start with <profile>. -migration Start with migration wizard. -ProfileManager Start with ProfileManager. -no-remote Open new instance, not a new window in running instance. -UILocale <locale> Start with <locale> resources as UI Locale. -safe-mode Disables extensions and themes for this session. -jsconsole Open the Error console. -browser Open a browser window. -new-window <url> Open <url> in a new window. -new-tab <url> Open <url> in a new tab. -preferences Open Preferences dialog. -search <term> Search <term> with your default search engine. -private Enable private browsing mode. -private-toggle Toggle private browsing mode. -setDefaultBrowser Set this app as the default browser. -g or --debug Start within debugger -d or --debugger Specify debugger to start with (eg, gdb or valgrind) -a or --debugger-args Specify arguments for debugger heaven:~/src>
I just assumed that -new-instance had made it into 12.0. I have been battling against a previous change to the -remote option since v. 188.8.131.52 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472793#22 + https://bugzilla.mozilla.org/show_bug.cgi?id=427206). Whatever happened to the -a option, which I have only ever seen documented in Debian + Ubuntu? "-a application-id Check for a running Firefox started with the specified application-id. When Firefox is invoked for the first time with a particular application-id, a new Firefox application is started; subsequent invocations of Firefox with the same application-id will cause the already running Firefox to bring up a new window [or new tab]. The default is -a firefox." It never worked as described. For me, multiple concurrent profiles are essential but it does not appear to be a popular feature. Is it available under Windows at all?
This feature is not available until FF 13.
thanks josh! i noticed this bug # isn't in the ff 13 release notes though. do you know if it slipped to 14? http://www.mozilla.org/en-US/firefox/13.0/releasenotes/buglist.html
I'm not sure how that list is generated, but the patch looks like it was checked in at the right time, so it should be present in FF 13.
confirmed, ff 13 does have this and it's working happily. yay, thanks all!
Thanks for this.
I just tried using -new-instance using Firefox 13.0.1 on Debian wheezy, and the -new-instance option did not work. I tried regular way "firefox -P pro2 google.com", tried it with -new-tab, -new-window, and with -browser. Maybe I'm doing something wrong? Thank You.
Ok, I got it to work, after I read Tarlika post on using the -remote command. Now since we can use the -remote command again, shouldn't that option be shown in help? I don't know if that would be a bug or not. Anyway, Thanks guys, you just made my day!
-new-instance is also not specified at https://developer.mozilla.org/en/Command_Line_Options I'd propose a fix myself, but I'm not sure about this whole BrowserID thing.
As of today -new-instance is noted ad "to be documented" in https://developer.mozilla.org/en/Command_Line_Options. However, it does not do what I expect it to do in conjunction with -P: open a browser window in given profile and be able to open a second tab (or window) in that profile. Here is my workaround script (derived form Tarlika's approach above on 2012-05-23). The script may be used for example as launch command in KeePassX as follows: firefox-in-profile.sh -P secureprofile -url #!/bin/sh PROFILE=$2 URL=$4 firefox -P $PROFILE -remote "ping()" if [ ! $? == 0 ]; then firefox -P $PROFILE -new-instance $URL else firefox -P $PROFILE -remote "openurl($URL,new-tab)" fi What I would like to have in Firefox is an option parameter that behaves like that script. I hope this script helps other people.
+1 Iceweasel does not open a new instance with DISPLAY=:1 iceweasel -no-remote -P ONE DISPLAY=:2 iceweasel -no-remote -P TWO DISPLAY=:1 iceweasel -new-instance -P ONE DISPLAY=:2 iceweasel -new-instance -P TWO Actually being able to run the same profile on 2 separate x sessions at the same time would be groovy. But at minimum separate profiles should work.
Is there anyone I can chat with about this on irc? I open new profile in my addon Profilist https://addons.mozilla.org/en-US/firefox/addon/profilist/ with -no-remote. I now would like to open a url in one of the parallel running profiles. I've tried combintations of -new-instnace, im not able to figure this out.
So this is the steps I'm doing. I click the firefox icon, this launches my default firefox profile. Then I go to run and run firefox.exe -P Dev -no-remote This launches my second profile. Then I do firefox.exe -P Dev -remote -new-tab "about:blank" but it doesnt seem to work :(
Ok (In reply to Ed Morley [:edmorley] from comment #11) > https://hg.mozilla.org/mozilla-central/rev/dce4363cb7ce > > Thanks for the patch Jed! (It will be present in the next Nightly) > > Join us on irc (#developers on irc.mozilla.org) and we'll find some other > things for you to work on if you are interested? :-D Hi there Ed i think this issue is unresolved. I have tried a lot of things but I can't get this (opening new tab with a url in a targeted profile) to work on Windows at least (im using 8.1). Can you please verify so we can reopen this bug. Thanks
Doing need info on person who marked this resolved. Platform is marked as "All" but this is not working on Windows. Please see Comment 35 https://bugzilla.mozilla.org/show_bug.cgi?id=716110#c35
(In reply to noitidart from comment #36) > Doing need info on person who marked this resolved. Platform is marked as > "All" but this is not working on Windows. Please see Comment 35 > https://bugzilla.mozilla.org/show_bug.cgi?id=716110#c35 Hi :-) I wasn't CCed until now, so sorry for not seeing your comments sooner. This bug is 2+ years old, so I think it's best to file a new one in the same product/component, add this bug's number (716110) to the "blocks" field of the new bug, explain the problem in the description, then needinfo the assignee of this bug and also the reviewer. I unfortunately can't help here, since I don't work on this code - I only closed the bug because I merged the commit from the integration repository to mozilla-central, since back then I was a tree sheriff (https://wiki.mozilla.org/Sheriffing). If you have any problems with filing the new bug, let me know :-)
(In reply to Ed Morley [:edmorley] from comment #37) > (In reply to noitidart from comment #36) > > Doing need info on person who marked this resolved. Platform is marked as > > "All" but this is not working on Windows. Please see Comment 35 > > https://bugzilla.mozilla.org/show_bug.cgi?id=716110#c35 > > Hi :-) I wasn't CCed until now, so sorry for not seeing your comments > sooner. > > This bug is 2+ years old, so I think it's best to file a new one in the same > product/component, add this bug's number (716110) to the "blocks" field of > the new bug, explain the problem in the description, then needinfo the > assignee of this bug and also the reviewer. > > I unfortunately can't help here, since I don't work on this code - I only > closed the bug because I merged the commit from the integration repository > to mozilla-central, since back then I was a tree sheriff > (https://wiki.mozilla.org/Sheriffing). > > If you have any problems with filing the new bug, let me know :-) Thanks Ed! I'll do that now :)
(In reply to Jed Davis [:jld] from comment #5) > Created attachment 590139 [details] [diff] [review] > Create a -new-instance flag for the functionality of the old -no-remote flag. > > Here, have a patch. I threw this together in a few minutes of actual > editing (ignoring the hours it took me to root-cause the mysterious failure > of -remote and find this PR), so approach with caution. > > I had -no-remote imply -new-instance, since it looks like people want it to > mean that all remoting is disabled. I did not have the combination of > -no-remote or -new-instance with -remote cause an error; it arguably should, > but I don't know if that'd be considered out of scope for this PR. There is > one "bonus fix", which is that I tried to correct -no-remote's existing > error messages, which looks to have been a victim of copy-and-paste. > > Testing done: verified that no-remote continues to not listen, that > -new-instance does what it says, and that multiple concurrent profiles can > be independently targeted with -P -remote. All ad-hoc, so I may have missed > something. Hi Jed, was this ever working on Windows? Or does it only work on linux? I filed a bug for windows and it looks like it was reproducible by others: https://bugzilla.mozilla.org/show_bug.cgi?id=1133731
I've been using (on linux) the workaround described in comment #31 for the last six months or so and it's been working flawlessly. However, my recent upgrade from ff35 to ff36 seems to have broke this behavior. Starting with ff36, this command: firefox -P myprofile -remote 'ping()' always opens a new ff window and always exits with a zero return code (regardless of what I supply as a remote command, even 'foo()' or whatever). :-(
(In reply to Thomas Dwyer III from comment #40) > I've been using (on linux) the workaround described in comment #31 for the > last six months or so and it's been working flawlessly. However, my recent > upgrade from ff35 to ff36 seems to have broke this behavior. Starting with > ff36, this command: > > firefox -P myprofile -remote 'ping()' > > always opens a new ff window and always exits with a zero return code > (regardless of what I supply as a remote command, even 'foo()' or whatever). > :-( Apparently it was intetionaly removed in F36 :( Totttally bummed and looking for an alternaive solution. https://bugzilla.mozilla.org/show_bug.cgi?id=1133731#c1
It seems the removal of the -remote option was instigated by someone who was unaware of the use cases that this functionality satisfied: https://bugzilla.mozilla.org/show_bug.cgi?id=1080319 Arguably, the real problem is not the removal of the -remote option, it's the fact that the -P option isn't honored when a firefox instance is already running: https://bugzilla.mozilla.org/show_bug.cgi?id=1138053
Hi all does anyone know if this is working yet for Windows?
You need to log in before you can comment on or make changes to this bug.