Closed Bug 855899 Opened 11 years ago Closed 5 years ago

-new-instance flag does not work

Categories

(Toolkit :: Startup and Profile System, defect, P5)

Product:
Toolkit
Component:
Startup and Profile System
Version:
63 Branch
Platform:
x86
Windows 10
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: fbrfa8.g, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:22.0) Gecko/20130323 Firefox/22.0
Build ID: 20130323031040

Steps to reproduce:

Attempted to start a new instance of firefox using the -new-instance command line flag


Actual results:

A new window on my already running instance of firefox appeared


Expected results:

A new instance of firefox should have started
INVALID then?
I need then processes to accept remote commands.

See this:
https://bugzilla.mozilla.org/show_bug.cgi?id=716110
I didn't close as INVALID because "-new-instance" isn't really documented and I don't know if it should work or not.
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
This flag works in linux, but not windows.  this should be fixed.
-new-instance doesn't actually do anything useful that a normal command doesn't.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> -new-instance doesn't actually do anything useful that a normal command
> doesn't.

I have no idea what you're talking about.  Have you tried reading https://bugzilla.mozilla.org/show_bug.cgi?id=716110
?
It works in linux but not on windows.  This should be fixed.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Priority: -- → P5
I can confirm it not working as expected on Windows 8. I was hoping to get a solution for a problem of opening links in different profiles, depending of the source of the link, no-remote doesn't work for this. So I would need it fixed.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> -new-instance doesn't actually do anything useful that a normal command
> doesn't.

are you suggesting that 
  thunderbird.exe -new-instance ...
is the same as 
  thunderbird.exe ...
Depends on: 716110
Flags: needinfo?(benjamin)
ok, if this is specifically about Windows then it should just be WONTFIX. I really shouldn't have let bug 716110 in without testing, but the remote mechanism is different on Windows and disabling it is hard and may cause side effects.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago → 11 years ago
Flags: needinfo?(benjamin)
Resolution: --- → WONTFIX
Did this ever work on Windows?  (And, if so, when?)  The history on X11 is that -no-remote used to mean "start a new instance instead of signaling an existing one" and didn't affect receiving remote commands, until bug 650078 changed it.  What I was trying to do in bug 716110 is get back the functionality that 650078 had taken away (because I, and a few others, actually use it).
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #10)
> ok, if this is specifically about Windows then it should just be WONTFIX. I
> really shouldn't have let bug 716110 in without testing, but the remote
> mechanism is different on Windows and disabling it is hard and may cause
> side effects.

I would like to nominate this for reopening.


The request is actually to "NOT" disable the remote function when using the -new-instance option. 

On windows:
   Using -no-remote to open two profiles at the same time results in two separate processes, one for each profile.
   This also disables the -remote mechanism completely, which results in not being able to programatically open a url in either profile. 

The -new-instance flag is completely ignored. 

On Linux: 
   Using -no-remote to open two profiles at the same time results in two separate processes, one for each profile.
   This also disables the -remote mechanism completely, which results in not being able to programatically open a url in either profile. 

Using the -new-instance flag instead results in two separate processes, one for each profile.
   This DOES NOT disable the -remote system, which results in being able to open a url in either profile via the command line. 

Steps to produce: 

1. _First create 3 profiles: 'DEFAULT', 'ONE', and 'TWO' 
        (assign DEFAULT to open without asking using profile manager)

    firefox -p ONE -new-instance
    firefox -p TWO -new-instance

2. _Attempt to open a new tab

    firefox -P ONE -remote "openurl(www.mozilla.com,new-tab)"

Windows Result: One Instance, two windows, New tab opens in only instance
Linux Result: Two separate instances, New tab opens in desired instance


DESIRED RESULT: 

Two separate instances, both with remote enabled. New tabs open in specified instance.
I'd like to second the request to reopen.  I also need to be able to open 2 profiles in separate instances, then send remote commands to either of them (running Windows).  -no-remote handles the first part, but does not allow the second.
Same here, I'd like this bug to be reopened. It is really annoying for web development...
+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.
I also want this...
I would also like to see this reconsidered.
I work with different profiles at the same time.
I use multiple browsers for different stuff, they all have different add-ons, settings, etc.
I really want this implemented.
I would like this bug to be reopened as I need to open 2 profiles in separate instances and to communicate with each instance.
I really want this implemented
I REALLY could use this FIXED as well...  SERIOUSLY!
I have my main install set to FF ESR v52.x for now because I rely on many XUL extensions..
but want to have a beta/archive version for testing Firefox Quantum 


v52.3 ESR  = C:\Program Files\Mozilla Firefox\firefox.exe
v57 beta 3 = C:\Program Files\Mozilla Firefox (v57+)(Quantum)\firefox.exe


I need to be able to have both open.. 
BUT trying to launch v57 beta 3, 
just opens a new tab in v52 with the copied profile name opening like as if it were a URL!
I'd also love this to be implemented on Windows. It's a dealbreaker for me when considering switching from Chrome to Quantum.
I don't know Windows very well, but I found what seems to be the code in question: https://searchfox.org/mozilla-central/rev/fe75164c55321e011d9d13b6d05c1e00d0a640be/toolkit/xre/nsNativeAppSupportWin.cpp#604

It looks like, to have multiple profiles running concurrently and still able to receive messages, there are some global names that would need to have the profile name added: the mutex at [1], the “window class” name at [2], and maybe others.  There's also a question of whether anything else depends on the existing names — and that might include third-party utilities, I think? — and, if so, how to keep the existing names in the non-multi-profile use case.


[1] https://searchfox.org/mozilla-central/rev/fe75164c55321e011d9d13b6d05c1e00d0a640be/toolkit/xre/nsNativeAppSupportWin.cpp#616
[2] https://searchfox.org/mozilla-central/rev/fe75164c55321e011d9d13b6d05c1e00d0a640be/toolkit/xre/nsNativeAppSupportWin.cpp#453
This feature needs to be fixed.  With Quantum, people have a strongly compelling reason to go back to Firefox.  Chrome handles multiple profiles at the same time in a graceful and intuitive manner.  Chrome also handles requests from other applications using whatever the last active profile window was in use.

I'm disappointed that Firefox still has not restored this feature and even more disappointed that this bug report was marked RESOLVED WONTFIX.
Is this a spite WONTFIX?
+1

it is a functionality supported by other browsers,
it is working on other platforms,
there are very good use scenarios,
I would say this means that this is a bug/limitation which should be fixed/implemented.

please remove the RESOLVED status,
so at least the discussion can be about how to do this and not if to do this.
I agree with papo, it's blamefully to keep this small bug 5 years open. Chrome developers laugh at you...
Is this a joke that this still is NOT implemented in 61.X? Seriously, you do not have to wonder if people stick to Chrome not just for the faster performance, but also because this feature works without any issues there. Shame on Mozilla!
I'd like to reopen this issue since there seems to be significant interest in this issue.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
OS: Windows 7 → Windows 10
Version: 22 Branch → 63 Branch
Given the mess of their code base I highly doubt that this will ever get addressed. Just stick to Chrome / Chromium, works a lot better.
I initally opened Bug 1477509 when I was trying to run PWA in Firefox, where 1 default profile is used for normal browsing and another one used as wrapper for PWA (which is, to hide the tab and awesome bar as well as color the window using userChrome.css and a bunch of extensions). Even though this works fine on Linux, I am currently considering to file a new bug about adding PWA support at the same Firefox profile, the same way as in Chrome. (GNOME Web/Epiphany uses separate profiles to handle each PWAs)
This is a necessary feature. I am curious to learn why it is so hard to implement the same thing I do when I manually create two profiles and have them work simultaneously, but clicking an URL from an application results in the "An instance of Firefox is already running" prompt instead of how Chrome handles it: Chrome prompts the user to choose which already-running profile to launch the URL with.
Btw: Why the bug is still "unconfirmed"? In my opinion it's clearified what's wrong and that's wrong...
needed this it doesn't work, CONFIRM.

In light of --new-instance being desupported on Linux I'd assume that supporting it on Windows is WONTFIX, but that's a decision for the module owner.

Flags: needinfo?(dtownsend)

Since bug 1518639 -new-instance now actually does something on Windows, but -no-remote and -new-instance are now largely pointless and may be removed at some point. See https://groups.google.com/forum/#!topic/mozilla.dev.platform/Vz-L_of5WZE

Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago → 5 years ago
Depends on: 1518639
Flags: needinfo?(dtownsend)
Resolution: --- → FIXED

I agree with the resolution because I feel that the Container feature now covers this use case.

(In reply to Kriston from comment #39)

I agree with the resolution because I feel that the Container feature now covers this use case.

Considering that this bug is about opening new instances from a command line and being able to select the separate instance when opening links from sources OUTSIDE of firefox.

Considering the following bugs for the containers plugin I would say that the specified needs are NOT being met:

https://github.com/mozilla/multi-account-containers/issues/365
(Container cmdline option when opening URLs)

https://github.com/mozilla/multi-account-containers/issues/706
(Prompt about which container to use when opening link from external application)

https://github.com/mozilla/multi-account-containers/issues/1340
(First tab in each new session always opens in the default container)

Again: this use case is STILL not being addressed by firefox, SIX YEARS after the ticket was originally opened about this feature having BEEN BROKEN.

I used to work.
Then it didn't and it's been in limbo ever since despite a stupid number of people asking about it on a regular basis for the better part of a decade.

It used to work for me, i had this alias for throwaway profiles, for finance and other purpose.

alias fx="/Applications/Firefox.app/Contents/MacOS/firefox --new-instance --profile $(mktemp -d)"

I always used to find myself in safe-zone with this new profile, I use container tabs but explicit new profile folder used to make me feel bit safe. Hoping it get picked up.

(In reply to Sumit Murari from comment #41)

It used to work for me, i had this alias for throwaway profiles, for finance and other purpose.

alias fx="/Applications/Firefox.app/Contents/MacOS/firefox --new-instance --profile $(mktemp -d)"

I always used to find myself in safe-zone with this new profile, I use container tabs but explicit new profile folder used to make me feel bit safe. Hoping it get picked up.

New instance was without any add-ons, so that was also helpful.
I have just never been to chrome before or after much marketed quantum release. Still firefox make me go to chrome for incognito mode.

(In reply to Sumit Murari from comment #41)

It used to work for me, i had this alias for throwaway profiles, for finance and other purpose.

alias fx="/Applications/Firefox.app/Contents/MacOS/firefox --new-instance --profile $(mktemp -d)"

I always used to find myself in safe-zone with this new profile, I use container tabs but explicit new profile folder used to make me feel bit safe. Hoping it get picked up.

This issue only affects Microsoft Windows...

(In reply to Dave Townsend [:mossop] from comment #38)

Since bug 1518639 -new-instance now actually does something on Windows, but -no-remote and -new-instance are now largely pointless and may be removed at some point. See https://groups.google.com/forum/#!topic/mozilla.dev.platform/Vz-L_of5WZE

If I understand correctly, this bug has been resolved as "this feature is being abandoned and will not be made to work" - so the choice of `FIXED' for this seems rather confusing: if someone is trying to report a problem with the (still clearly documented) "--new-instance" flag not working, and they manage to come here (first result in Google), and the label says "FIXED" in 2018 - while the feature clearly does not work - it is very confusing.

I suggest to change the resolution to WONTFIX, and also removing these flags from the documentation, as they clearly aren't intended to ever work again.

(In reply to Oded Arbel from comment #44)

(In reply to Dave Townsend [:mossop] from comment #38)

Since bug 1518639 -new-instance now actually does something on Windows, but -no-remote and -new-instance are now largely pointless and may be removed at some point. See https://groups.google.com/forum/#!topic/mozilla.dev.platform/Vz-L_of5WZE

If I understand correctly, this bug has been resolved as "this feature is being abandoned and will not be made to work" - so the choice of `FIXED' for this seems rather confusing: if someone is trying to report a problem with the (still clearly documented) "--new-instance" flag not working, and they manage to come here (first result in Google), and the label says "FIXED" in 2018 - while the feature clearly does not work - it is very confusing.

To my recollection this is not correct. Bug 1518639 fixed -new-instance to work on Windows as it does on other platforms, so what this bug was filed for is now fixed. However, like on all platforms, -new-instance is not a terribly useful flag. Just passing an argument to select a profile that isn't in use will now give you a new Firefox instance whether this flag is present or not. All this flag does is alter the case when you launch Firefox with a profile that is already in use, without this flag Firefox will simply activate the existing Firefox instance using the profile, with this flag Firefox will refuse to start because the profile you are trying to use is in use and locked.

If you're seeing issues where -new-instance is not behaving like this then please file a new bug and we can look at it.

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