Bug 1029139

Summary:	-P parameter for command-line profile specification not working
Product:	[Fedora] Fedora	Reporter:	John Florian <jflorian>
Component:	firefox	Assignee:	Martin Stransky <stransky>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	19	CC:	gecko-bugs-nobody, stransky
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-01-07 10:46:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description John Florian 2013-11-11 18:21:33 UTC

Description of problem:
firefox -h reports:

<snip>
  -P <profile>       Start with <profile>.
<snip>

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:
always

Details:
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 14:05:50 UTC

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 21:57:33 UTC

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 07:50:21 UTC

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.