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.
Status: UNCONFIRMED → RESOLVED
Closed: 6 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 :-(.
(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" 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". : 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.)
Status: RESOLVED → UNCONFIRMED
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8378212 - Flags: review?(benjamin)
Status: ASSIGNED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.