Last Comment Bug 716110 - split -new-instance flag out of existing -no-remote flag
: split -new-instance flag out of existing -no-remote flag
Status: RESOLVED FIXED
: dev-doc-needed, relnote
Product: Toolkit
Classification: Components
Component: Startup and Profile System (show other bugs)
: unspecified
: All All
: -- normal with 4 votes (vote)
: mozilla13
Assigned To: Jed Davis [:jld] [away until 06-01] [⏰MDT; UTC-6]
:
Mentors:
: 716361 (view as bug list)
Depends on: 1133731
Blocks: 855899
  Show dependency treegraph
 
Reported: 2012-01-06 15:20 PST by Ryan
Modified: 2015-05-26 00:57 PDT (History)
22 users (show)
noitidart: needinfo? (jld)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Create a -new-instance flag for the functionality of the old -no-remote flag. (2.66 KB, patch)
2012-01-20 01:12 PST, Jed Davis [:jld] [away until 06-01] [⏰MDT; UTC-6]
benjamin: review+
Details | Diff | Review

Description Ryan 2012-01-06 15:20:25 PST
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...
Comment 1 Ryan 2012-01-13 13:21:58 PST
ping?
Comment 2 Ryan 2012-01-18 16:00:29 PST
[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!
Comment 3 Alex Garel 2012-01-20 00:41:12 PST
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)'
Comment 4 Alex Garel 2012-01-20 00:42:28 PST
*** Bug 716361 has been marked as a duplicate of this bug. ***
Comment 5 Jed Davis [:jld] [away until 06-01] [⏰MDT; UTC-6] 2012-01-20 01:12:25 PST
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.
Comment 6 Josh Matthews [:jdm] 2012-01-20 01:45:14 PST
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.
Comment 7 Ryan 2012-01-20 08:13:43 PST
agreed, awesome, thank you jed! I'll try the patch too. looking forward to seeing it in a release!
Comment 8 Benjamin Smedberg [:bsmedberg] 2012-01-23 07:16:58 PST
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 9 Benjamin Smedberg [:bsmedberg] 2012-02-06 12:15:06 PST
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.
Comment 10 Josh Matthews [:jdm] 2012-02-06 12:19:31 PST
http://hg.mozilla.org/integration/mozilla-inbound/rev/dce4363cb7ce

Thanks Jed!
Comment 11 Ed Morley [:emorley] 2012-02-07 12:07:33 PST
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
Comment 12 neil@parkwaycc.co.uk 2012-02-08 01:45:23 PST
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?
Comment 13 [Baboo] 2012-02-08 03:25:13 PST
https://developer.mozilla.org/en/Command_Line_Options should be also updated/clarified to reflect bug 650078 and this bug.
Comment 14 edward.chapin 2012-02-22 01:08:07 PST
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!
Comment 15 Ryan 2012-02-22 11:11:14 PST
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.
Comment 16 edward.chapin 2012-02-23 00:54:30 PST
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.
Comment 17 Ryan 2012-02-23 12:16:53 PST
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?
Comment 18 edward.chapin 2012-02-24 02:54:47 PST
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...
Comment 19 Ryan 2012-02-24 08:25:37 PST
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?
Comment 20 Tarlika Elisabeth Schmitz 2012-05-23 11:53:53 PDT
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?
Comment 21 Ryan 2012-05-23 12:05:40 PDT
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>
Comment 22 Tarlika Elisabeth Schmitz 2012-05-23 14:14:12 PDT
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. 2.0.0.13 (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?
Comment 23 Josh Matthews [:jdm] 2012-05-23 16:33:28 PDT
This feature is not available until FF 13.
Comment 24 Ryan 2012-06-05 15:07:44 PDT
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
Comment 25 Josh Matthews [:jdm] 2012-06-05 15:33:58 PDT
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.
Comment 26 Ryan 2012-06-06 10:44:53 PDT
confirmed, ff 13 does have this and it's working happily. yay, thanks all!
Comment 27 Alex Garel 2012-06-12 01:21:46 PDT
Thanks for this.
Comment 28 dt1059 2012-06-16 21:48:01 PDT
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.
Comment 29 dt1059 2012-06-19 10:45:34 PDT
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!
Comment 30 Terrell Kelley 2012-06-20 00:47:20 PDT
-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.
Comment 31 Hayo 2014-06-29 06:22:48 PDT
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.
Comment 32 supersonicsnow 2014-11-04 06:42:51 PST
+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.
Comment 33 noitidart 2015-02-08 04:25:39 PST
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.
Comment 34 noitidart 2015-02-08 04:38:57 PST
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 :(
Comment 35 noitidart 2015-02-16 20:03:48 PST
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
Comment 36 noitidart 2015-02-16 20:05:21 PST
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
Comment 37 Ed Morley [:emorley] 2015-02-17 02:26:46 PST
(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 :-)
Comment 38 noitidart 2015-02-17 06:25:11 PST
(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 :)
Comment 39 noitidart 2015-02-23 01:06:34 PST
(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
Comment 40 Thomas Dwyer III 2015-03-03 13:28:34 PST
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). :-(
Comment 41 noitidart 2015-03-03 13:50:25 PST
(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
Comment 42 Thomas Dwyer III 2015-03-03 15:10:02 PST
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
Comment 43 noitidart 2015-05-26 00:57:50 PDT
Hi all does anyone know if this is working yet for Windows?

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