716110 - split -new-instance flag out of existing -no-remote flag

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Ryan]

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]

ping?

Comment 2

[Ryan]

[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]

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 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Attachment: 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]]

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]

agreed, awesome, thank you jed! I'll try the patch too. looking forward to seeing it in a release!

Comment 8

[Benjamin Smedberg]

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]

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]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/dce4363cb7ce

Thanks Jed!

Comment 11

[Ed Morley [:emorley]]

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

[[e-mail]]

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]]

https://developer.mozilla.org/en/Command_Line_Options should be also updated/clarified to reflect bug 650078 and this bug.

Comment 14

[edward.chapin]

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]

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]

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]

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]

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]

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]

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]

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]

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]]

This feature is not available until FF 13.

Comment 24

[Ryan]

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]]

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]

confirmed, ff 13 does have this and it's working happily. yay, thanks all!

Comment 27

[Alex Garel]

Thanks for this.

Comment 28

[dt1059]

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]

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]

-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]

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]

+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]

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]

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]

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]

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]]

(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]

(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]

(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]

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]

(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]

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]

Hi all does anyone know if this is working yet for Windows?

Comment 44

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

So I probably should've answered this needinfo a long time ago with “no, sorry; I don't know much about the Windows side”, but I was hoping that someday I'd be able to do something. I did briefly take a look at the code and post some thoughts in bug 855899 comment #23, but I don't have a Windows development environment.

However, --new-instance no longer works even on Linux (which is a problem for me personally given that I'd been using --new-instance with remoting to a specific profile, and now I guess I have to figure out DBus or something?), so it seems unlikely at this point that it will ever work on Windows.