Closed Bug 1564083 Opened 1 year ago Closed 11 months ago

Launching with -profile does not select a named profile using the same directory (because the local profile directories don't match).


(Toolkit :: Startup and Profile System, defect, P3)

67 Branch



Tracking Status
firefox72 --- fixed


(Reporter: contact, Assigned: mossop)




(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

I use to run several separate instances of Firefox, one of which being the "main" one and should open links from other applications.

I have a script that does the following :
firefox -profile "$HOME/.mozilla/firefox/Profile1" &
firefox -no-remote -profile "$HOME/.mozilla/firefox/Profile2"

Actual results:

Both Firefox instances open correctly when I run this script.
However, when clicking a link in another application, the system tries to run another Firefox instance. Because (presumably) this new instance tries to use the same profile, it fails with the "Close Firefox" error message.

Expected results:

Clicking a link in a third application should create a new tab within the Firefox instance that is not run with the -no-remote parameter.

This is what had been happening in the past (I have been doing this for several years) ; I do not remember encountering this problem before upgrading to FF67.

Note : if manually run an instance by just invoking firefox and if this instance really gets to live (ie. the profile it tries to use is not already locked), then this instance correctly receives and opens links from third apps. This is the reason I believe there is a bad interaction when -profile is specified.

Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit

What is your default profile?

Flags: needinfo?(contact)

(In reply to Dave Townsend [:mossop] (he/him) from comment #1)

What is your default profile?

It is the profile that is intended as "remote" ("$HOME/.mozilla/firefox/Profile1" in my example).

I just tried to create a fresh profile to serve as default profile : after running my usual script (which does not do care about default profile), clicking a link in a third party app causes a new Firefox instance to open with this profile, and subsequent links also open in tabs in this new (unwanted) instance.

So it seems the problem is really that my instance started with firefox -profile "$HOME/.mozilla/firefox/Profile1" does not assume its role as "remote".

Flags: needinfo?(contact)

No this doesn't really have anything to do with remoting. This is an issue I keep meaning to get around to doing something about. Launching with -profile makes Firefox think you are using a different profile to one that might be listed in the profiles database because the two end up using different directories for local storage. So when launched normally (from the other application) it cannot find an instance of Firefox already using the default profile.

Generally the recommended way to launch a specific profile from the database from the command line would be to use -P <profile name> which should solve your issue.

Priority: -- → P3
Summary: -profile seems to imply -no-remote → Launching with -profile does not select a named profile using the same directory (because the local profile directories don't match).

Thanks for you input but I have to differ.
I just rewrote my startup script as follows.


if [ $# == 0 ]; then
    firefox -P Yann-1 &
	firefox -no-remote -P Yann-2 &
	firefox -no-remote -P Yann-4 &
	if [ $num == 1 ] ; then
		np="-no-remote "
		firefox $np -P Yann-$num &

Running it creates the instances I want. But I still get the same behaviour : links from other apps are opened in a new instance running the default profile (which is not any of these 3).

Duplicate of this bug: 1572289
Assignee: nobody → dtownsend
Pushed by
The profile command line argument should match a profile with the same root directory and use its local directory. r=froydnj
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
You need to log in before you can comment on or make changes to this bug.