Build 2001091508, Win2K. Open a Mozilla browser window. Then open profile manager using "mozilla.exe -ProfileManager" command. It opens a new window with the home page, instead of doing nothing (and warning about not being able to run profile manager while mozilla is running).

.

No dupes found. Marking NEW. -> Profile Manager BackEnd

this belongs to commandline apps!

Needs another case in HandleRequest that ignores -ProfileManager (and others) when already running. -console would be nice to actually get working in this case, BTW.

*** Bug 107535 has been marked as a duplicate of this bug. ***

Mass moving bugs that won't get fixed this milestone.

balancing move of Helper App Mgt feature work bugs to this milestone

*** Bug 111553 has been marked as a duplicate of this bug. ***

re-assigning 'several bugs at once' to morse@netscape.com.

nsbeta1- per ADT triage team, ->future.

*** Bug 138813 has been marked as a duplicate of this bug. ***

*** Bug 169788 has been marked as a duplicate of this bug. ***

I experienced the same with Phoenix. The first time I opened Phoenix0.4 with the -profilemanager only displayed a window with the height set to 0 and only being able to close the window. Then I opened Phoenix several times and now the profile manager only returns a browser window without any message being displayed.

*** Bug 182567 has been marked as a duplicate of this bug. ***

Just in case somebody forgot, it is still happening with 20021130 (ver. 1.2.1) W2K. Somebody with admin rights could change the status from NEW. :)

same here with 2002121215

Reassigning to module owner

Now Mozilla can bring up the profile manager while the app is still running (Tools | Switch Profile) I think the command line should now bring up the profile manager even when Mozilla is already running. Therefore I think this should be looked into again.

Nav triage team: nsbeta1-

*** Bug 205495 has been marked as a duplicate of this bug. ***

Bug still present in v1.4 ( w2k ).

*** Bug 283314 has been marked as a duplicate of this bug. ***

*** Bug 234114 has been marked as a duplicate of this bug. ***

I have the similar bug in Firefox 1.5 on FreeBSD. Profile Manager comes up when there are no firefox instances running and lets you choose the profile. Further invocations of the command results in use of the same profile that was selected earlier. I am not able to run multiple firefox profile. For now switched to different browsers (Firefox, Mozilla, Opera) :(. It was fine on the older version Firefox 1.0.7.

I'm seeing this with firefox 1.5 on Linux. BTW, I don't want to change the profile the running firefox is using when I do this; I want to start a new process using a different profile.

I concur with Harish and Mark, with firefox 1.5 I can no longer to multiple running instances of firefox (under different profiles) on Linux and NetBSD. With firefox 1.0.2 I would start up multiple instances by running "firefox -ProfileManager" and picking a different profile. Now "firefox -ProfileManager" just opens a window using the already running instance. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060110 Debian/1.5.dfsg-4 Firefox/1.5

Also, the -P <profile> flag doesn't work anymore. This is really quite an annoying bug, since it makes multi-user use of firefox on the same machine quite difficult.

cf. Same bug for Linux: bug 99828

Seeing this behavior with Firefox 1.5.0.1 running on SuSE Linux 10.

Duplicated this bug on 1.5.0.1, Fedora Core 5. Additionally I confirmed that it is firefox-bin ignoring the argument, and not one of the startup scripts dropping the command-line argument on the floor. Neither -ProfileManager nor -P <profilename> has any effect if a Firefox instance is already running.

(In reply to comment #24 to comment #27 and comment #29 to comment #30) If no problem when Fx 1.0.x but problem started to occur after Fx 1.5, problem you are seeing is probably Bug 308076.

*** Bug 257083 has been marked as a duplicate of this bug. ***

is bug 286355 a partial solution/blocker ? related: bug 295693 [enh] dups? bug 98696, bug 326075, bug 335345, bug 346217, bug 325937

*** Bug 327849 has been marked as a duplicate of this bug. ***

Confirmed that this problem has returned in 2.0.0.13. Tested on Kubuntu 7.10, and verified again that it is firefox-bin, not one of the wrapper scripts: $ env LD_LIBRARY_PATH=/usr/lib/firefox:$LD_LIBRARY_PATH /usr/lib/firefox/firefox-bin -Profilemanager pops open a new window of the running Firefox instance, instead of running Profilemanager.

Currently, the situation on Windows versions is the following: 2.0.0.13 : not working as expected (a browser window is opened, per bug description) Trunk (nightly 2008041907) : works as expected

On linux you can use the --no-remote option or MOZ_NO_REMOTE=1 environment variable to use -P or --profilemanager while an app is running. I'm told they work the same on windows, which is the platform this bug is marked as being relevant on. Presumably the expected results here are that --profilemanager should imply --no-remote, and -P should remote to an instance running the specified profile?

I think this bug should be resolved as WONTFIX. Think about this scenario: if you create a shortcut to a Mozilla app with --profilemanager switch only, you can select one profile and start the app. If you open the shortcut another time, why the app shouldn't be restarted? This is the common behaviour of all programs. Furthermore as written in the previous comment, profile manager can be started with the --no-remote parameter.

This bug had quite enough visibility (hence, some importance) when the profile manager could be invoked right from the Start Menu (Windows systems). Since long time ago, Firefox has dropped that feature (I don't know whether Seamonkey or other derivatives are still providing it). So this bug is a minor issuer now, for FF at least. Whoever knows how to invoke the profile manager, can cope with this bug without major annoyance.

Take a look to the suggestion I filed in Bug 441422.

(In reply to comment #39) > I think this bug should be resolved as WONTFIX. Think about this scenario: if > you create a shortcut to a Mozilla app with --profilemanager switch only, you > can select one profile and start the app. If you open the shortcut another > time, why the app shouldn't be restarted? This is the common behaviour of all > programs. That is against the logic. I said --profilemanager in the command line. That means I do really want to see a profile manager. I've also checked the box to always show me profile manager. That also means I do really want to see it. Then firefox comes, **** my wish up, **** its documentation up and thinks it is smarter than a user. It just says me: you do not want it, I know better what do you need. Just like Microsoft. This effectively makes profile manager useless. Why not just remove it at all? Let it be like IE -- if you want to have another profile, just relogin as another user. The ideology of the product will be clear then and it can be safely removed and forgotten. Who needs another IE? We have one IE already. > Furthermore as written in the previous comment, profile manager can be started > with the --no-remote parameter. Yes it can. Then you cannot open a second link from an external application. Very annoying.

(In reply to comment #40) > Whoever knows how to invoke the profile manager, can cope > with this bug without major annoyance. The problem exactly is that I do not know how to invoke the profile manager. There is no way to do so. FF just ignores -P option if one instance is running. I.e. that is not a stupid cosmetics bug.

(In reply to comment #41) > Take a look to the suggestion I filed in Bug 441422. No remote means no OS integration. You cannot handle external links then. This will just add more inconstancy with the documentation. The feature should work just as documented -- if I've requested profile manager, I should get it. That simple.

If you read better Bug 441422, you see I proposed to run multiple profiles __wihtout__ --no-remote. My suggestion was wontfixed. Have you see one of my comments with some swearwords?

(In reply to comment #45) > If you read better Bug 441422, you see I proposed to run multiple profiles > __wihtout__ --no-remote. > My suggestion was wontfixed. Have you see one of my comments with some > swearwords? OK, you are right. So isn't it the same with this bug then? Still your problem with _testing_ can probably be solved with an additional --no-remote option. This does not solve a _normal use_ of FF by two different people on the same PC, however.

It's not the same at all, please read carefully comment 0

Broken for me on Linux (Gentoo) with 3.0.1. Not only will -ProfileManager fail to open the profile manager if an instance is running, it will silently ignore a profile you specify explicitly with -P <profile>. In other words if an instance "default" is running and I run "firefox -P other", it will open a new window with profile "default". Insideous. This worked fine with 2.0.0.16.

@JM: You can run multiple profiles only if you add also --no-remote parameter, as already written before.

Thanks Lucas, I understand that. I was just agreeing with other people that the new behavior is a bug and a regression from 2.0.0.16 (for me).

How about making Firefox to check if A1) parameter "--profilemanager" is set A2) there's already any running instance of Firefox If A1 and A2 then behave as "--no-remote" had been also used. (Currently "--profilemanager" flag is ignored in this case.) Similarly, check if B1) parameter "-P" is set B2) there is NO instance of Firefox running with the same profile name If B1 and B2 then behave as "--no-remote" had been also used. (Currently "-P" flag is ignored in this case.) Kind of trying to make "-P" or "--profilemanager" to work as most users expect without fully implementing what bug 441422 requsts.

(In reply to comment #51) > How about making Firefox to check if > A1) parameter "--profilemanager" is set > A2) there's already any running instance of Firefox > If A1 and A2 then behave as "--no-remote" had been also used. (Currently > "--profilemanager" flag is ignored in this case.) That would have the same drawback -- one cannot start a second copy of the same profile. I.e. the use of --no-remote makes it impossible to open a second external link. One need to copy the link and paste it into FF instead. That is annoying.

I don't think that's really a problem. If you have two instances of Firefox open (with different profiles) and you click a link in an external app, I think it's fine if the first one "wins".

(In reply to comment #53) > I don't think that's really a problem. If you have two instances of Firefox > open (with different profiles) and you click a link in an external app, I think > it's fine if the first one "wins". I do not "think". I do have real problem. That is first. The second problem is -- you do not have two profiles open w/o --no-remote (no way to open it) and you cannot open a second one with a click from external app with --no-remote. In fact most of the users who comment in this topic do not have two profiles. Otherwise they would know how it really works. I.e. they do not need profile manager at all (or at least not for a purpose it was created for, i.e. to have several users).

I don't understand comment 54 at all.

(In reply to comment #55) > I don't understand comment 54 at all. Let's put it simple: in a proposed fix --no-remote would be silently used. With --no-remote a new window will be open instead of a new tab in existing one. One cannot load a second copy of the same profile, because it's locked. I.e. instead of a win of some copy there will be an error message about locked profile.

I can't understand why you need to run two instances for the same profile

(In reply to comment #57) > I can't understand why you need to run two instances for the same profile If I click on external link it will run a new instance of FF in case of --no-remote. I do not need two instances (and cannot get them working). That's why --no-remote is not a solution.

(In reply to comment #58) @Stanislav Mekhanoshin: see Bug 441035

Why INCOMPLETE ? What is missing ? The bug is still there in v3.0.10.(WinXP) Starting PM brings up a new FF window.

I think in the haste to do bug 491354 some bugs were marked incomplete just to close them. but this bug is really WONTFIX based on prior art of bug 362355 and bug 308076

I have developed a patch for this which causes -profilemanager to imply -no-remote. Further, while here, I added a two-line chunk which causes -p <profile> to only contact a remote also running in that profile, if any, and fail otherwise. The bulk of the patch is actually spent fixing a bug in CheckArg for the rare case when it is not removing arguments.

Comment on attachment 713799 [details] [diff] [review] Proposed patch; commentary forthcoming >Fix https://bugzilla.mozilla.org/show_bug.cgi?id=99828 by making -profilemanager imply -no-remote: I won't r+ this change and I can't imagine making -profilemanager imply -no-remote will ever be acceptable since there are use cases where it shouldn't. bsmedberg knows this code much better than I

What are those use cases?

Running a different profile than the default one and wanting os integration.

Are you saying that -no-remote influences both whether we reuse a running process, and whether "OS integration" features work? Maybe we should fix that!

(In reply to Jesse Ruderman from comment #69) > Are you saying that -no-remote influences both whether we reuse a running > process, and whether "OS integration" features work? Maybe we should fix > that! It does and always has though it does much less now that we no longer use DDE on Windows. You should let bsmedberg weigh in on this since he knows this code and why it was implemented in these ways.

I guess that's roughly the subject of bug 441422 and bug 382477?

If the -profilemanger implying -no-remote part of the patch is objectionable, skip it; the other two hunks are much more important to me, FWIW.

Comment on attachment 713799 [details] [diff] [review] Proposed patch; commentary forthcoming CheckArg is so unreadable now, any change there needs some kind of comment. In any case, I do not want to support the other pieces of this bug. Profiles are stored as directory paths, not named, and so through restarts etc we won't preserve profile names and people will not get the behavior they expect. I don't want to support the code and tests that would be necessary to actually get correct named-profile behavior. That's why this bug was WONTFIXed in the first place, and I will continue to confirm that decision.