Last Comment Bug 352074 - profile management broken
: profile management broken
Status: RESOLVED WONTFIX
DUPEME?
:
Product: Firefox
Classification: Client Software
Component: Shell Integration (show other bugs)
: unspecified
: x86 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Alon Zakai (:azakai)
:
: Robert Strong [:rstrong] (use needinfo to contact me)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-10 15:19 PDT by Tom
Modified: 2011-04-08 13:00 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Tom 2006-09-10 15:19:04 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060731 Ubuntu/dapper-security Firefox/1.5.0.5

I have three profiles, let's call them "default", "user", and "anon".

What I would expect to happen is that "firefox -P someprofile" makes sure that there is exactly one firefox process running for profile "someprofile" and then opens a new window for the browser running with that profile.

Well, that's not what happens. 

"firefox -P default" always seems to open a new window in whatever firefox is already running, even if it's running a different profile.  When choosing "default" through the profile manager, however, the "default" profile behaves like "user".

"firefox -P user" starts a new firefox process for profile "user" if one isn't already running and opens a window.  But if one is already running, it complains that I "first need to quit" the running firefox process and then doesn't start up a new one.

(The firefox developers should probably also rethink how firefox works in a distributed X11 environment, where multiple instances of firefox may be using the same X11 display but running on different hosts and even as different users.)

Reproducible: Always

Steps to Reproduce:
Create multiple profiles, then try to start them up with "firefox -P something" and "firefox -ProfileManager".

Actual Results:  
Sometimes opens windows for the wrong profile, sometimes refuses to start up firefox (see above).

Expected Results:  
The profiles should behave as if each of them were the default profile for a single-profile user; they just happen to share the same display.
Comment 1 Aaron Racine 2007-06-04 14:04:53 PDT
I can reproduce some of this with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/0000000000 Firefox/2.0.0.4 (Ubuntu-edgy).

Using the "firefox -P <profile>" syntax, I can open a new browser window for each profile if one is not already running.  If one is already running for that profile, I get a dialog box that says:  

"Firefox is already running, but it is not responding.  To open a new window, you must first close the existing Firefox process, or restart your system."

I was not able to reproduce the reported behavior that the default profile would sometimes open a new window in the wrong profile.  I launched it at least 10 times, and I got the "already running" dialog box every time.
Comment 2 Aaron Racine 2007-06-04 16:48:36 PDT
Sorry, that wasn't tested with an official build.  Tested again with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/2007051502 Firefox/2.0.0.4.  The results are more in line with the report now.

If there are no Fx windows open, then "-P <profile>" does what you'd expect.

If there is an existing Fx process open with profile A, all subsequent executions of "firefox -P <profile>" will open a new window using profile A, regardless of the profile specified by <profile>.  So, if I started with default and then tried profile A and then profile B, there would be three windows open with the default profile.  If I started with profile A and then tried profile B and then the default profile, there would be three windows open with profile A.

Using this build, I never saw the message about an unresponsive Fx process that I previously reported.

A work-around is to use --no-remote.  "firefox -P <profile> --no-remote" did what I expected every time.

Reporter, can you confirm that you get the expected results if you use --no-remote?
Comment 3 Benjamin B. 2007-10-23 14:20:33 PDT
Me, I have two profiles here, running Firefox 2.0.0.8 on a Linux box (Ubuntu Gutsy). One is the default profile, one is called Java. The Java profile button also gives the --no-remote argument.
The following happens:
- When no firefox is running, the chosen profile is loaded when I start Firefox. As expected.
- When I only have the default profile running:
    - firefox -P default opens a new window with the default profile. Perfect.
    - firefox -P Java opens a new window with the Java profile. Fine.
- When I only have the Java profile open:
    - firefox -P Java opens a new window with the Java profile. Also fine.
    - firefox with any arguments ("-ProfileManager" or "-P default") opens a new window with the Java profile. This is not what I expect.

Cheers
Comment 4 Jim Hill 2010-07-07 13:46:25 PDT
the problem with -no-remote is that if there is already an instance open with that profile, firefox will refuse to open the new url
Comment 5 Alon Zakai (:azakai) 2011-04-03 20:06:08 PDT
I can confirm the above, namely,

1. Firefox -P someprofile opens a new window in the current profile running in another Firefox window, not someprofile

2. Firefox -P someprofile --no-remote opens a new window in the right profile, but if one already is open for that profile, then the "Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system" error is shown.

And I agree both are very counterintuitive. I'll work on a patch.
Comment 6 Benjamin Smedberg [:bsmedberg] 2011-04-08 13:00:48 PDT
As noted in at least one other bug, I will not accept a patch for this; it increases the complexity of the remoting feature somewhat significantly for little benefit.

Note You need to log in before you can comment on or make changes to this bug.