Option -ProfileManager does not work without (bogus) -u

Bug #1226952 reported by era
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Firefox
New
Unknown
firefox (Ubuntu)
Opinion
Undecided
Unassigned

Bug Description

You need a secret extra option if you want to run the Firefox profile manager.

Steps to repro:

bash$ firefox -ProfileManager &

Expected outcome:

New Firefox instance displaying the Profile Manager dialog box

Actual outcome:

New Firefox browser window in your current default profile, existing Firefox instance if one was running

Workaround:

bash$ firefox -u bugger -ProfileManager &

The -u option is not visible e.g. in firefox --help output, but somehow it actually exists, and allows you to work around this problem (can't remember where I discovered it, Google no doubt?).

The -u option requires an argument (apparently, a profile name) but you can put anything there, it doesn't seem to matter.

I'm sorry if this is a duplicate, this problem has existed since basically forever but I was unable to find a report in Launchpad.

Historical proof:

* From 2009: http://ubuntuforums.org/showthread.php?t=1323430
* From 2011: http://forums.mozillazine.org/viewtopic.php?f=9&t=2359133
* SuSE 2009: http://forums.opensuse.org/english/get-technical-help-here/network-internet/403948-firefox-profilemanager-doesnt-work.html
* Win 2011: https://support.mozilla.org/en-US/questions/807487
* Alternative workaround, haven't tried: http://www.usmessageboard.com/computers/85692-firefox-profile-manager-in-ubuntu.html (hopelessly meandering thread, don't open)

Possibly relevant upstream bugs:

* https://bugzilla.mozilla.org/show_bug.cgi?id=317903
* https://bugzilla.mozilla.org/show_bug.cgi?id=297470 (duplicate of less focused 264181)
* https://bugzilla.mozilla.org/show_bug.cgi?id=264181
* https://bugzilla.mozilla.org/show_bug.cgi?id=297618 (duplicate of unobvious bug)

If the intention is that -ProfileManager is not available, it should not be displayed in --help (but that would be a pity). If it is supported, it should work (duh).

bash$ lsb_release -rd
Description: Ubuntu 12.04.3 LTS
Release: 12.04

bash$ apt-cache policy firefox
firefox:
  Installed: 24.0+build1-0ubuntu0.12.04.1
  Candidate: 24.0+build1-0ubuntu0.12.04.1
  Version table:
 *** 24.0+build1-0ubuntu0.12.04.1 0
        500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
        500 http://mirrors.nic.funet.fi/ubuntu/ precise-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     23.0+build2-0ubuntu0.12.04.1 0
        500 http://fi.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
     11.0+build1-0ubuntu4 0
        500 http://fi.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

Revision history for this message
In , error10 (error-ioerror) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1) Gecko/20090630 Fedora/3.5-1.fc11 Firefox/3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1

The -P (-ProfileManager) command line option to Firefox does not work on Linux as expected if Firefox is already running. A workaround is available.

Reproducible: Always

Steps to Reproduce:
1. Create two or more Firefox profiles and uncheck the "Don't ask at startup" option in Firefox Profile Manager.
2. Start a copy of Firefox with one profile.
3. Start a second copy of Firefox with "firefox -ProfileManager".
Actual Results:
The running copy of Firefox opens a new window with the defined home page using the original profile.

Expected Results:
A new copy of Firefox should start with the Profile Manager open, to choose or
create a new profile, or start with the profile specified on the command line,
if any.

Workaround: Using -no-remote along with -ProfileManager causes the Linux version to open Profile Manager; this is not necessary on Windows. The expected behavior is how Firefox already behaves on Windows. This issue seems specific to Linux. (Lacking a Mac, I was unable to test the Mac OS X build.)

Using -ProfileManager should start a new copy of Firefox regardless of whether -no-remote is given, as it does on Windows, since this is the behavior users will expect. Using -ProfileManager implies that the Profile Manager will actually be opened; requiring a second command line option to open it is confusing. At the very least, the Windows and Linux builds should handle this command line option the same way, to reduce user confusion.

For instance, it is possible for an unwary user to attempt to start a second profile using, e.g. firefox -P SecondProfile and think that the new profile is in use when the new window appears, when the new window is part of the originally opened profile. The unwary user could inadvertently compromise his own security if he wants to use multiple profiles to segregate his browsing activities, as many people do.

Revision history for this message
In , Cwwmozilla (cwwmozilla) wrote :

Actually it IS necessary on Windows. You need no-remote on all OSes to start a second instance.

Revision history for this message
In , error10 (error-ioerror) wrote :

That's interesting; on my Windows Vista box I was able to start Profile Manager without it by using firefox -ProfileManager from the command prompt, at least once. Now I've tried it again and indeed it does open a new window. Apparently I was hallucinating.

In any case I still believe that -no-remote should not be necessary when -ProfileManager is given, because it leads to a confusing user experience, so I've changed this bug to "enhancement".

Revision history for this message
In , Davemgarrett (davemgarrett) wrote :

Hallucinations generally produce iffy bug reports.

Dupe of bug 441422 or do you just want -P to imply -no-remote?

Revision history for this message
In , error10 (error-ioerror) wrote :

I don't think it's quite the same as bug 441422, since I can live without OS Integration (though it would be nice, it apparently would also be "an extreme amount of complexity to implement"). I would be happy if -P implied -no-remote. Alternately, a way to explicitly open the Profile Manager (e.g. from the Tools menu) to start a new instance of Firefox. That's apparently been a very long-standing feature request.

Revision history for this message
In , TimSmall (tim-seoss) wrote :

It may be worth noting that various Linux distributions have fixed this bug in the past e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356250

era (era)
description: updated
Revision history for this message
In , Era+mozilla (era+mozilla) wrote :

This should be CONFIRMED with a vengeance. This bug has existed like forever.

If -ProfileManager is supported, then it should work without additional chicanery (so I guess comment #3 applies), or else it should not be displayed in --help etc (but that would suck; multiple profiles are a very useful feature).

I reported a downstream bug with additional notes for Ubuntu: https://bugs.launchpad.net/firefox/+bug/1226952 -- in particular, I have links to half a dozen old Mozilla bugs which should probably be marked as duplicates of this one (and it's easy to find more).

Changed in firefox:
importance: Unknown → Wishlist
status: Unknown → New
Revision history for this message
era (era) wrote :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356250 has a patch which was apparently once applied to Ubuntu's firefox to fix this precise issue. The old bug is LP bug #31746. It was closed as Won't Fix for unclear reasons many years ago.

(I tried to link the Debian bug here as "also affects distribution ..." but Launchpad throws a timeout error for that.)

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

This isn't really a bug (or certainly not something we're going to change in Ubuntu). Firefox is single instance, so when you try to run new Firefox instance when there is one already running, the entire command line is delegated to the already open instance.

If you want to use "-Profilemanager" when you already have Firefox open, then you need to also use "-no-remote" to ensure that a new Firefox instance is opened (which is documented). We even state this in the manpage that we add to Firefox.

"-u" is not documented because it's an internal implementation detail. It "works" in your case because you are using it incorrectly which results in the remoting of the command line failing.

Changed in firefox (Ubuntu):
status: New → Opinion
Revision history for this message
In , Jpyobjcdude (jpyobjcdude) wrote :

I run OpenSuse and --ProfileManager worked for a few months. It just stopped working in the last month or so. I'm on OpenSuse 42.2 and Firefox 52.1.0 x64

Using the -u switch does get around this problem on my system.

Changed in firefox:
status: New → Unknown
Changed in firefox:
status: Unknown → New
Changed in firefox:
importance: Wishlist → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.