317040 - Only one profile can be active at one time

Status: RESOLVED DUPLICATE of bug 271191

(Toolkit :: Startup and Profile System, defect)

Description

[Stefan Becker]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 Red Hat/1.0.7-1.4.1 Firefox/1.0.7
Build Identifier: Firefox 1.5 RC3

[Originally reported to RH bugzilla against Fedora Core development version of 1.5rc1, see URL]

Firefox 1.5 currently seems only to be able to handle one profile at a time, ie. if you start it with one profile you can't start another instance using another profile.

Reproducible: Always

Steps to Reproduce:
1. Setup firefox with two profiles: profile1, profile2
2. firefox -P profile1
3. firefox -P
4. firefox -P profile2

Actual Results:  
3. Opens new window in the "profile1" instance
4. Opens new window in the "profile1" instance


Expected Results:  
3. Start new instance showing profile manager
4. Start new instance using profile2


I took the Rawhide SRPM and was able to compile it for RHEL4 after minor modifications (disable pango, disable system cairo, nspr -> mozilla-nspr). After noticing the profile problem I tried to re-compile with 

 "ac_add_options --disable-single-profile"

added to firefox-mozprofile but then the build fails with:

gmake[1]: Entering directory `/workarea/rpm/BUILD/mozilla/profile/src'
nsProfile.cpp
c++ -o nsProfile.o ...
In file included from nsProfile.cpp:39:
nsProfile.h:46:31: nsICmdLineService.h: No such file or directory
nsProfile.cpp:80:34: nsIChromeRegistrySea.h: No such file or directory
...
gmake[1]: *** [nsProfile.o] Error 1
nsProfileAccess.cpp
c++ -o nsProfileAccess.o ...
In file included from nsProfileAccess.cpp:41:
nsProfile.h:46:31: nsICmdLineService.h: No such file or directory
gmake[1]: *** [nsProfileAccess.o] Error 1

It seems that the current Firefox 1.5RC1 only compiles for single profile usage...

Comment 1

[Stefan Becker]

One additional note: The profiles I'm using are the ones I've created with FireFox 1.0.X. They work fine with FF 1.0.7

Comment 2

[Benjamin Smedberg]

*** This bug has been marked as a duplicate of 271191 ***

Comment 3

[Elmar Ludwig]

See also the RFE/bug 308076, which I think would have been the better bug to dup this against...