Closed Bug 287896 Opened 20 years ago Closed 20 years ago

multiple instances of FX should be able to use different profiles

Categories

(Firefox :: General, enhancement)

x86
Windows 98
enhancement
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: phild, Assigned: bugzilla)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-AU; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-AU; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 My requirement is that I want to run two or more concurrent instances of FX on the same machine with DIFFERENT profiles. If I have one instance running with my default profile I often want to be able to run another instance with another profile, typically a vanilla profile or a profile which has just one extension that I want to try in a "sterile" environment. I want to be able to switch back and forth between these different instances to study FX's behaviour perhaps before reporting a bug in the CORE when it is actually in an extension. Currently under v1.0.2 when I start the first instance of FX I am presented with the "which profile" dialogue, if I start another instance of FX I am NOT presented with the "which profile" dialogue and all nth instances use the same profile as that chosen in the first instance. Basically I want all instances of FX to give me the "which profile" dialogue. Reproducible: Always Steps to Reproduce: 1. establish mutiple profiles 2. start FX selecting say default profile 3. start another instance of FX, note you are not asked to select a profile Actual Results: FX starts with the profile selected in the first instance, which given that it did not ask in the second instance is a reasonable thing to do. Expected Results: asked whch profile on the 2nd instance.
see bug 222661 comment 1 for a workaround
MOZ_NO_REMOTE will do this, except for hooking into running profiles. That's the extent of what we're going to implement in the forseeable future.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
*** Bug 311932 has been marked as a duplicate of this bug. ***
That translates to $ export MOZ_NO_REMOTE=1 $ firefox if you are running Linux and use Bash as your shell. This way the Profile Manager window opens. But I don't understand, why does $ firefox --profilemananger fail to open the Profile Manager (and instead opens a new browser window using the current profile) if Firefox is already running? Do you agree, I should open a new bug for that :-) BTW: Runinng Firefox 1.5 RC3
*** Bug 318284 has been marked as a duplicate of this bug. ***
I'd like to know why this request is rejected: What are the intricacies and ramifications of implementing it? Why not set "MOZ_NO_REMOTE" implicitly when the user asks for "-profilemanager"? Maybe we can discuss this in MozillaZine http://kb.mozillazine.org/Talk:Profile_Manager ?
This strikes me as a serious usability bug with profile support. Multiple profile support is useful for creating specialized profiles for tasks like paying bills. It makes multiple profile use extremely awkward compared to previous versions of Firefox when any existing browser sessions have to be closed to open a different profile. I would think this should work on all platforms as a standard feature. I view multiple profile support as a big advantage over Internet Explorer and other lesser browsers. Are there any known side effects of using the MOZ_NO_REMOTE=1 workaround? A somewhat obscure but useful technique under bash and similar unix shells is to place the environment variable assignment as a prefix to the actual command, which makes the environment variable assignment privately scoped to that one command, eg.: MOZ_NO_REMOTE=1 firefox -P This technique is useful for one liners especially for contexts like GUI launches. Maybe this should be documented? Is the issue with fixing this item one of which profile to join when running "firefox" again without the -P option?
For the "--ProfileManager doesn't open a profile-manager" bug, see bug 99828 (for windows) and bug 308076 (for linux).
You need to log in before you can comment on or make changes to this bug.