-new-instance flag does not work

RESOLVED FIXED

Status

()

defect
P5
normal
RESOLVED FIXED
6 years ago
2 months ago

People

(Reporter: fbrfa8.g, Unassigned)

Tracking

63 Branch
x86
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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?
(Reporter)

Comment 3

6 years ago
I need then processes to accept remote commands.

See this:
https://bugzilla.mozilla.org/show_bug.cgi?id=716110

Comment 4

6 years ago
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
(Reporter)

Comment 5

6 years ago
This flag works in linux, but not windows.  this should be fixed.

Comment 6

6 years ago
-new-instance doesn't actually do anything useful that a normal command doesn't.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 7

6 years ago
(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 → ---

Updated

6 years ago
Priority: -- → P5

Comment 8

6 years ago
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
Last Resolved: 6 years ago6 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).

Updated

6 years ago
Duplicate of this bug: 918681

Comment 13

6 years ago
(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.

Comment 14

5 years ago
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.

Comment 15

5 years ago
Same here, I'd like this bug to be reopened. It is really annoying for web development...

Comment 16

5 years ago
+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 17

3 years ago
I also want this...

Comment 18

3 years ago
I would also like to see this reconsidered.

Comment 19

2 years ago
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.

Comment 20

2 years ago
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

Comment 21

2 years ago
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!

Comment 22

2 years ago
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

Comment 24

2 years ago
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.

Comment 25

a year ago
Is this a spite WONTFIX?

Updated

10 months ago
Duplicate of this bug: 1477509

Comment 27

10 months ago
+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.

Comment 28

10 months ago
I agree with papo, it's blamefully to keep this small bug 5 years open. Chrome developers laugh at you...

Comment 29

9 months ago
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!
(Reporter)

Comment 30

9 months ago
I'd like to reopen this issue since there seems to be significant interest in this issue.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
(Reporter)

Updated

9 months ago
OS: Windows 7 → Windows 10
Version: 22 Branch → 63 Branch

Comment 31

9 months ago
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.

Comment 32

9 months ago
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)

Comment 33

9 months ago
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.

Comment 34

8 months ago
Btw: Why the bug is still "unconfirmed"? In my opinion it's clearified what's wrong and that's wrong...

Comment 35

6 months ago
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
Last Resolved: 6 years ago2 months ago
Depends on: 1518639
Flags: needinfo?(dtownsend)
Resolution: --- → FIXED

Comment 39

2 months ago

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

Comment 40

2 months ago

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

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