Bug 1029139 - -P parameter for command-line profile specification not working
-P parameter for command-line profile specification not working
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-11-11 13:21 EST by John Florian
Modified: 2014-01-07 05:46 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-07 05:46:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Florian 2013-11-11 13:21:33 EST
Description of problem:
firefox -h reports:

  -P <profile>       Start with <profile>.

However, this does not work and appears to be mishandled by the shell script wrapper.

Version-Release number of selected component (if applicable):
firefox-25.0-3.fc19.x86_64 (and numerous prior versions)

How reproducible:

I have two profiles (for two different computers accessing the same home directory via NFS).  The first profile, named "default" is my main one and the other is "alt" for the alternate workstation.  If I use "-P default", firefox will use the last profile used (ignoring the requested profile option) and opens a page for a site named "default.com", apparently through assumed TLDs or a search result.  If I eliminate the space (i.e., "-Pdefault") firefox opens a default blank page (as it should), but again does not use the requested profile but whatever profile I had last used.

The only consistent way I can get firefox to use a desired profile is to either bypass the wrapper script (i.e., calling /usr/lib64/firefox/firefox directly) or by using the interactive ProfileManager option.

Expected results:
I was hoping to have a pair of KDE keyboard shortcuts to launch one profile or the other using the -P option, but that seems only possible by bypassing the shell script, which probably causes other problems.
Comment 1 Martin Stransky 2013-11-12 09:05:50 EST
I'm unable to reproduce with Firefox 25 on Fedora 19. For instanve I run "$firefox -P t1 -no-remote" which launches a new firefox session with t1 profile...
Comment 2 John Florian 2013-11-12 16:57:33 EST
My KDE shortcuts are as follows:

Ctrl-Alt-X: firefox -P default -new-window about:blank
Ctrl-Alt-Y: firefox -P alt -new-window about:blank

I just now added the "about:blank" part because I see that "-new-window" expects a URL which I was not providing.  So that explains why I got sent to default.com.  However, I still find the -P option being ignored if I do the following, all on one computer/one user session for ease of testing:

1. Shutdown all FF instances.
2. Press Ctrl-Alt-X, which correctly launches a new instance using the default profile.
3. Press Ctrl-Alt-Y, which opens a new window, but with the default profile rather than the alt profile as requested.

I cannot use the "-no-remote" option or the "-new-instance" option which it implies because I want to use this shortcut whenever I want another browser window.  I often have dozens already open that I want to leave as is for when I come back to them, but simply want a keyboard shortcut for launching more.  Ordinarily, I'd only use Ctrl-Alt-X on the first workstation and only Ctrl-Alt-Y on the second workstation.  Ideally, I wouldn't even need two profiles but that seemed to be the only way I was going to have two instances of FF running from the same home directory.

Do I need to create my own wrapper that uses flock against a file in my home that contains the hostname (or perhaps profile name would be better) so that if the lock is new, I also pass -new-instance but if already locked, I leave that option off and do as I have currently in my shortcuts?
Comment 3 Martin Stransky 2013-11-13 02:50:21 EST
If firefox is running it does not start under different profile unless the -no-remote parameter is given. If launched with -no-remote it creates a new window of course.

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