Closed Bug 973371 Opened 7 years ago Closed 7 years ago

Profile Manger not clear enough about which profile is/will be "default"


(Toolkit :: Startup and Profile System, defect)

24 Branch
Windows XP
Not set





(Reporter: naesten, Assigned: emk)




(2 files)

Using: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 ID:20140131092626 CSet: d06a17a96fa2

I started "firefox.exe -no-remote -p foo", then tried to run just "firefox.exe", but the latter gave me the "Firefox is already running but is not responding" shpiel.

However, it worked when I then tried "firefox.exe -p default".

It seems to me that, rather than complaining about this while looking for an instance to "remote" to, the win32-remote code should instead skip over any -no-remote instances here and let the app continue trying to start.  If it fails to acquire the profile lock, *then* it should complain.

(This might require win32-remote to create a window -- or whatever it uses for an IPC point -- with a special "-no-remote" marker in -no-remote instances.)
Component: General → Startup and Profile System
Product: Core → Toolkit
Firefox is trying to load the profile and finding it's locked. That's where the message comes from. Presumably "firefox.exe" is trying to use the foo profile.
Closed: 7 years ago
Resolution: --- → INVALID
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)

Hmm, yes, sorry about that.  I guess I was taking the name "default" a bit too literally :-(.
Attached image ProfileManager.png
(Note: "foo" was actually "firebug".  This seemed embarrassing when I was filing for some reason.)

Hmm, it's not at all clear to me why it's trying to load the "firebug" profile instead of the "default" profile.

Note: most of the things I ran were via 
Here are events as I can recreate them:

1. I ran "firefox.exe -no-remote -p firebug"[1] before the profile existed.

   This popped up a dialog box that I see is entitled: "Choose User Profile".

   (Though at the time, I just thought "Ah, the Profile Manager" w/o reading the
   title.  Possibly due to having seen the "-ProfileManager" flag somewhere.)

2. I did the "Create Profile" dance to create the "firebug" profile.

   This will have returned me to that dialog, with the "firebug" profile
   highlighted, as in the attached screenshot.

3. I most likely clicked "Start Firefox" at this point.

At no time was there any indication that I was changing the default profile to start to anything other than "default", or that it was even possible to change the default profile away from "default".

[1]: There might have actually been a "-jsconsole" here too, but it doesn't seem particularly relevant.
Er, um, except that last profile obviously wasn't listed just yet ...

(I had forgotten that I took that screenshot *before* deleting the 4th profile.)
Resolution: INVALID → ---
"Don't ask at startup" will update the default profile.
To work around this bug (or design), I always take the following step to create a new profile.
1. Run "firefox -no-remote -p foo". The Profile Manager will pop up.
2. Create the "foo" profile from the Profile Manager.
3. Click "Exit". (If I choose the created "foo" profile and click "Start Firefox", the default profile will be switched to "foo").
4. Run "firefox -no-remote -p foo" again. The Profile Manager will not be displayed this time because the profike is already created. Firefox will start using the profile "foo" without changing the default.
> "Don't ask at startup" will update the default profile.

Probably the label should have been something like "Use the selected profile without asking at startup".
Summary: "-no-remote" process on a non-default profile blocks argument-less startup → Profile Manger not clear enough about which profile is/will be "default"
Assignee: nobody → VYV03354
Ever confirmed: true
Attachment #8378212 - Flags: review?(benjamin)
Attachment #8378212 - Flags: review?(benjamin) → review+
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Depends on: 975817
QA Whiteboard: [good first verify]
You need to log in before you can comment on or make changes to this bug.