441422 - Impossible to run multiple profiles without --no-remote parameter

Status: RESOLVED WONTFIX

(Toolkit :: Startup and Profile System, defect)

Description

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

If you want to run multiple profiles with Firefox, you must specify --no-remote parameter. But with --no-remote parameter you can't open a link or a page in Firefox that comes from another app or from local.

I suggest to add the possibility to run multiple profiles also without --no-remote. If Firefox is invoked from remote, and 'Don't ask at startup' is checked, the default profile should be loaded if it's not already running. If it's running, a new tab should be created to load the link passed by remote, with no new process.
If 'Don't ask at startup' is _not_ checked, when a link is opened by remote the Profile Manager should be shown to choice with which profile you want to open the link. The behaviour for already running profiles should be the same as described before.

Please check if this bug occurs also on Linux and Mac. See also comments on Bug 441035.

Steps to reproduce (1):
1) Create a shortcut to firefox.exe with --profilemanager parameter.
2) Open a profile with this shortcut
3) try to open another profile with this shortcut
Actual result: Profile Manager is not shown the second time, but another window for the current profile is opened. See also Bug 99828.

Steps to reproduce (2):
1) Create a shortcut to firefox.exe with --profilemanager --no-remote 
   parameters.
2) Open a profile with this shortcut
3) Try to open a page or link from another app or from local. If you have not 
   checked 'Don't ask at startup', reselect the same profile.
Actual result: as expected, the remote execution can't be performed in the already running process, and Firefox can't share the same profile with more than one process.

Comment 1

[Robert Strong (they/them - no direct email)]

This is essentially the same as bug 441035 and IMO is WONTFIX... I'll let bsmedberg decide though.

-no-remote is specifically for not integrating with the OS *and* links from external apps are specifically integration with the OS.

At best today you can open one instance of the app with OS integration and a profile so it will handle links from the OS and have other instances of the app opened with -no-remote and separate individual profiles.

Over to XRE Startup since this is about supporting something other than OS Integration.

Comment 2

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(In reply to comment #1)
> This is essentially the same as bug 441035
The base concept is similar, but in Bug 441035 I misunderstood the meaning of the parameter and I proposed to permit to processes started with --no-remote to open remote links, that is a nonsense.

> -no-remote is specifically for not integrating with the OS *and* links from
> external apps are specifically integration with the OS.

Exactly. This is why now you can't open links with other apps with multiple profiles. 
I don't want to open external links in processes opened with --no-remote. I simply want to start multiple profiles _without_ --no-remote, but only with --profilemanager.

This is extremely useful for bug testing. I normally use to switch between my normal profile and a blank profile. And if I must test bugs that requires some add-on installations or changes, I create another blank profile and I do my tests on it. You can imagine a simpler handle method of external links with multiple profiles opened will be extremely useful, and it will resolve much problems I currently have with other apps that try to open links when Fx is running.

> At best today you can open one instance of the app with OS integration and a
> profile so it will handle links from the OS and have other instances of the 
> app opened with -no-remote and separate individual profiles.

Yes, I thought this workaround in Bug 441035 Comment 2. It seems to me a bad solution because you can only open remote links in one running profile, and you must do two shorcuts and remember to open the right one.

Comment 3

[Robert Strong (they/them - no direct email)]

(In reply to comment #2)
> (In reply to comment #1)
>...snip
> > -no-remote is specifically for not integrating with the OS *and* links from
> > external apps are specifically integration with the OS.
> 
> Exactly. This is why now you can't open links with other apps with multiple
> profiles. 
> I don't want to open external links in processes opened with --no-remote. I
> simply want to start multiple profiles _without_ --no-remote, but only with
> --profilemanager.
What it seems that you are proposing is a central point during startup that allows you to choose between different profiles whether the profile is already in use or not and whether OS Integration is enabled or not. That is an extreme amount of complexity to implement especially for multiple profiles which is not the use case for the majority of users.

> This is extremely useful for bug testing. I normally use to switch between my
> normal profile and a blank profile. And if I must test bugs that requires some
> add-on installations or changes, I create another blank profile and I do my
> tests on it. You can imagine a simpler handle method of external links with
> multiple profiles opened will be extremely useful, and it will resolve much
> problems I currently have with other apps that try to open links when Fx is
> running.
All of the above can be mitigated by testing with -no-remote and using your normal profile simultaneously except in the cases where you are testing opening urls from the OS.

Comment 4

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

(In reply to comment #3)
> What it seems that you are proposing is a central point during startup that
> allows you to choose between different profiles whether the profile is already
> in use or not and whether OS Integration is enabled or not. 

Yes.

> That is an extreme amount of complexity to implement

...(sigh)

Comment 5

[Kai Liu]

Workaround: Change the Name= field in applications.ini instead of using -no-remote or -p (you'll need a separate installation of Firefox for each instance, but that's usually not a problem since the only time this would be really useful is when testing different versions)

Comment 6

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Well, I use it also to test things in blank profiles for trunk.

Comment 8

[nkostis]

(In reply to comment #5)
> but that's usually not a problem since the only time this would be
> really useful is when testing different versions)

well here at work we're doing some scalability testing with firefox (to determine whether it'll be used in a large scale project) and right now it's impossible to place a new tab inside a specific profile/process.
Hence this fix would be useful even without testing different versions and we can't have 100 different installations to support 100 profiles (or more) with an X number of tabs inside each.

Comment 10

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

I was thinking those days about this bug, and I think there's a simple workaround: --no-remote implicit if Firefox is already running. What do you think about?

Comment 11

[klonos]

...coming from bug 634547 and after reading through all the related/linked issues I honestly cannot understand why this persistence to be setting all issues related to this VERIFIED PROBLEM to "wontfix" or "invalid". I do understand that we need to get fx 4.0 out the door soon, but come on now!

We need to get around this. People need to keep the functionality of opening external links in firefox once it is set as their default browser while at the same time they use multiple profiles (because they need to test new features/addons/builds or whatever else reason they have).

OK, -no-remote is there "to disable remote stuff". We get that. What we don't understand is why we need to use it in order to run multiple profiles. I mean, is it the issues titles/descriptions that are misleading or something? Should we rephrase it to "Allow running multiple profiles without -no-remote because then we loose the functionality of opening external links in the default browser" or something? What?

Please people. This is an actual problem that many of us are facing and it needs to be addressed. You cannot simply reply with "We won't fix it because that's what we've decided" and throw this as a reply to our legitimate requests + on top of that marking them as "invalid".

Comment 12

[Benjamin Smedberg]

You can launch one Firefox without -no-remote to handle external launching, and the rest need -no-remote. But multiple profiles are not a design priority and we will not accept the significant amount of new code that would be required to make them actually work correctly.

Comment 15

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

From Bug 634114 comment 1:
"we could iterate through the profiles, and if any are locked, assume
that another instance is running and add -no-remote automatically.  This would
only fail if someone had an orphaned profile lock on their machine"

IMO this is a simple and effective solution.

I don't think this is a behaviour that affects few people, if you do a rapid search: http://preview.tinyurl.com/6y666wb
I think Mozilla will have more help if life is less hard for us dumb debuggers.

Comment 19

[Ancoron]

Sorry to revive this dead bug, but I just want to note something:

I am currently still happily using multiple profiles without the need for -no-remote. In my case at least (here on Ubuntu 15.04, Firefox 38.0), it is enough to specify -new-instance, which preserves the remoting.

For easy handling, I've written a small proxy script that gets called instead of the original Firefox command, which looks whether a specific profile instance already exists, and if so, makes use of the now deprecated -remote 'openURL(<url>)' command to open new URLs in the desired profile, e.g.:

New profile:
    firefox -new-instance -P <profile>

New URL for profile:
    firefox -P <profile> -remote 'openURL(<url>)'

New URL for profile in new window:
    firefox -P <profile> -remote 'openURL(<url>,new-window)'

However, it looks like this is not going to work in a future version and there is no newer, non-deprecated functional equivalent.

Comment 21

[hifromnz]

This doesn't work anymore in FF v64, 64 bit, Windows 8

If it solved the problem, why has it been deprecated and can it be un-deprecated???

(In reply to Ancoron from comment #19)

> I am currently still happily using multiple profiles without the need for
> -no-remote. In my case at least (here on Ubuntu 15.04, Firefox 38.0), it is
> enough to specify -new-instance, which preserves the remoting.

> e.g.:
> 
> New profile:
>     firefox -new-instance -P <profile>

> However, it looks like this is not going to work in a future version and
> there is no newer, non-deprecated functional equivalent.

Comment 22

[hifromnz]

This old chestnut has been around for at least 11 years, numerous bug reports.

Despite the extreme efforts of Lucas Malor (many thanks from your fellow sufferers for your efforts Lucas) and all us others, it has just been repeatedly binned.

No longer just devs using multiple profiles.  Multiple profiles are now commonly used by normal users like me for security reasons (far better than buggy containers which have WORSE problems opening external links).

As can be seen, EVERYBODY needs to open external links.  IDK what possible purpose disabling that could have.

No-remote obviously does 2 things: 
1. allows multiple profiles to run simultaneously.
2. prevents remote links opening.

No Brainer: need a switch (or DEFAULT) that allows multiple profiles, but does not disable remote links. How hard is that???

I note that, if an instance of FF is STARTED from an external link  via profile manager, all subsequent links are opened in that profile without asking.  (I am guessing that the external link opens the profile without no-remote.) That also is a bug:  when running multiple profiles users want to be able to choose which profile to open each link in, and either open a closed profile or open a tab in the active window of an already open profile, as Lucas Malor has carefully explained above.

Please reopen this bug, get brave, and fix it!!!

Comment 23

[hifromnz]

A further observation: when an additional (CLOSED) profile is opened from an external link via profile manager there is no "already running" error, despite other profiles already being open.  So it looks like the multiple profiles issue is already resolved there - maybe a clue to the solution???

If "use profile without asking" is selected in profile manager when opening that first link, ALL links subsequently clicked open in that profile without a choice, until it is closed.  If the box is unticked, the next link returns "already running" error if the same profile is selected.  What a dogs breakfast-minefield in your browser.)

To clarify - allowing multiple profiles should be DEFAULT behaviour of FF.  Some clever person in prehistoric times may have had a reason to prevent it, that reason no longer exists.  As well as security, we use it for space management so profiles do not get too big.  We also use different addons in different profiles.

Comment 24

[hifromnz]

https://bugzilla.mozilla.org/show_bug.cgi?id=855899

Comment 25

[hifromnz]

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

Comment 26

[Florian Quèze [:florian]]

(In reply to hifromnz from comment #21)

If there's a new problem, you want to express it in a new bug. Commenting in an old closed bug won't help.

Comment 27

[Ian Beveridge]

New bugs get marked as dupes of this bug, and this bug seems to exist purely for the purpose of being aggressively ignored. (Looks like a lot of legitimate comments have been deleted on this one too?)

I use Chrome, and wanted to switch to Firefox because in Chrome I can easily have a work profile and a home profile and they run simply, separately and intuitively (Desktop shortcuts to open each profile, and external links are opened in the last window interacted with).

TBH I bought a memory upgrade and kept Chrome anyway. Seemed like the simplest option.