Closed Bug 365462 Opened 18 years ago Closed 17 years ago

Firefox 2.x no longer recognizes the command "- profilemanager"

Categories

(Firefox :: General, defect)

2.0 Branch
x86
Linux
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: jsairy, Unassigned)

Details

(Whiteboard: CLOSEME 07/14)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061115 Ubuntu/dapper-security Firefox/1.5.0.8
Build Identifier: Ubuntu

It seems the Profile Manager does not function properly.  If on the commandline the command "firefox -P 'Profilename'" or "firefox -profilemanager" no longer does anything.  It is as if the function has changed in how it is to be executed. . . but obviously the command should still be the same.  

Reproducible: Always

Steps to Reproduce:
1. run in anyway "firefox -profilemanager" and nothing will occur the browser will come up with default profile or previously set one
2. run "firefox -P 'profilename'" and it ignores the requested profile in favor of opening a new window of an already opened profile
3.
Actual Results:  
see above

Expected Results:  
when runing "firefox -p 'Profilename'" or "firefox-P 'Profilename'" it shoult open the profile regardless of what is opened and never open the default, but only open the requested profile

I think this may be a problem in older releases but I seem to be able to work fine in firefox-1.5.0.8, although it will not allow new windows of the same profile open at once. . .
Version: unspecified → 2.0 Branch
Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!
Whiteboard: CLOSEME 07/14
I'm not the reporter, but I'm having the same problem.

About box says:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
A little more detail: if I'm already running firefox, then firefox -ProfileManager opens a new frame.  if I am not running firefox, then firefox -ProfileManager brings up the profile manager.  However, I used to be able to use this command to have two different profiles running simultaneously, and this no longer works.
If you're on 2.0 and you want to open multiple versions of firefox with different profiles, you have to also pass -no-remote

firefox.exe -no-remote -p <profilename>
Ah, that works.  Thanks!

I would suggest, then, that -ProfileManager or -P should imply -no-remote, since those flags are meaningless if remote is enabled.  At the very least, a warning would help, instead of behavior which is indistinguishable from ignoring the flag.

Finally, the -h usage message does not mention -no-remote at all.
--> INVALID (you can't invoke profile manager if firefox is already running without -no-remote)
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
I'm not sure what you mean by "can't" here.  I'm currently running firefox, which I ran with no command line options.

if I run "firefox -ProfileManager", my existing firefox instance pops up a new window, which I think is a bug (it's never what the user wants)

if I run "firefox -ProfileManager -no-remote" then I get a profile manager window and I can start a window under a new profile.  I think this is should always be the behavior when -ProfileManager is specified.
So this is an enhancement request then? If firefox is already running, and you try and start another instance with firefox.exe -profilemanager, it should pop the profile manager and allow you to select a different profile? (And presumably stop you from selecting any profile that is currently being used so you don't have to firefox.exe's playing with the same profile)?
I think it's a bug, not an enhancement request, that "firefox -ProfileManager" does not always give me the profile manager.  It is certainly a regression from 1.5.

The behavior you describe is exactly the behavior "firefox -ProfileManager" had in 1.5, and exactly the behavior that "firefox -ProfileManager -no-remote" has today.

All I'm saying is that -ProfileManager should imply -no-remote, but it does not.

Also, -no-remote should be documented in the usage message.
You need to log in before you can comment on or make changes to this bug.