Closed Bug 1553815 Opened 5 years ago Closed 5 years ago

New instances of Firefox use the default profile, even if there is already running instance using another profile

Categories

(Toolkit :: Startup and Profile System, defect)

67 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: katoda, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

  1. Firefox 67, two profiles created and listed in profiles.ini - profile1, marked as default and profile2. Firefox is set as default browser and it is the only Firefox installation on the PC.
  2. Launch Firefox with profile2 using the parameter -P "profile2" (e.g. by having a separate desktop shortcut launching Firefox with the command ""C:\Program Files\Mozilla Firefox\firefox.exe" -P "profile2"
  3. Launch another Firefox instance without any parameters - e.g. by a shortcut created during installation,by the command "C:\Program Files\Mozilla Firefox\firefox.exe" or by clicking a link in Thunderbird email or in instant messaging Windows client.

Actual results:

A separate instance of Firefox is launched, using the default profile "profile1".

Expected results:

Firefox should recognize that another instance of the same application is running, switch to that instance and open a new tab in the currently opened Firefox window.
This was a default behaviour of Firefox 66 and below. Apparently the functionality related to multiple versions of Firefox and multiple profiles, introduced with Firefox 67, does not take into account situation when the user launches another instance of the same version of Firefox. It is logical that it should use the same profile as currently running instance - default profile should be used only if there is no Firefox running and the launch command does not specify the profile.

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

Correction: "does not take into account situation when the user launches another instance of the same version of Firefox" should be read as "does not take into account situation when the user launches another instance of the same installation of Firefox".

This is the intentional behaviour since Firefox 67. If you want to open a new tab in an existing instance of Firefox you must launch Firefox in a way that targets the profile for that instance.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

But how I'm supposed to launch Firefox in that way if Firefox is launched by another process (e.g. RSS client or IM client)? They just launch the default web browser and usually do not give the user any possibilities to customize the launch command.

The expectation is that you'd always want launches by other applications to open in the default profile.

So now having more than one profile does not make any sense. Firefox launched by other processes will always use the default profile, so keeping other users' profiles is now in 90% useless.

The expectation is that you'd always want launches by other applications to open in a NOT -no-remote'd session - be it the "default" profile, or any other profile (already) opened NOT -no-remote'd.
(And if no NOT -no-remote'd session is open, then sure, default to opening "default".)

(If there existed the ability to have launches by other applications to open in particular -no-remote session, that's fine too.
But AFAIK, that cannot be done - at least in Windows.
An explanation of what the current behavior [FF 67] is, what expected behavior is [the two may not be the same], command-line options, explanation of installs.ini... would certainly be nice, because as it is, there is a dearth of information to be found [at least that I have found].)

The expectation is that whatever mechanism you use to launch Firefox we select a profile (based on either command line arguments or just using the default for that install). If that profile is already open in another instance of Firefox then it will just open a new tab in that instance. So a given way of launching Firefox will consistently open the same profile.

But this logic does not take into account that there are ways of launching Firefox that user simply cannot control - working with a non-default profile and then having Firefox launched by another process is just an example of such situation. If I launched Firefox with a specific profile, I expect that any attempt to run again the same Firefox executable will reuse what I'm using right now. Current implementation turns this logic upside down, putting more weight on how things are run, not how they are used. It does not see that similar ways of running Firefox may have different source behind (e.g it treats in the same way the situation when Firefox from manually launched from command line or automatically launched by another process) and - as a result - a different outcome is expected from launch.

The following probably is not a common configuration, but I just wanted to mention what happens for me on Windows 10 in Firefox 67:

(1) Firefox 67 is the default browser.

In the Windows Registry, the shell command for URLs points to release (developer edition is the second installation).

(2) My main shortcut has -P "Quantum" (this does not use -no-remote)

This profile generally runs 24x7 and is my preferred target for external links.

(3) A second shortcut has -P -no-remote (calls up the Profile Manager dialog)

I generally use this second shortcut just for brief testing and close that browser when I'm done with it. Whenever it is used, it changes the default profile in both installs.ini and Profiles.ini. (Changing the default is not especially useful for me but I'm not aware of a way to avoid it when using the Profile Manager dialog.)

(4) When I use an external URL link, if the default profile has been changed to something other than Quantum, Firefox shows the Profile Manager dialog. I then need to select Quantum to have the link open as a new tab in the running browser; this updates the default profile in both installs.ini and Profiles.ini.

For some reason, the initial link is very slow to load. However, subsequent external links load speedily as usual.

I'm not quite sure why it's working this way, but perhaps it is this in my Profiles.ini file:

[General]
StartWithLastProfile=0

That corresponds to clearing the checkbox for "Use the selected profile without asking at startup" in the Profile Manager dialog.

Dear Jscher2000 and Dave Townsend,

Jscher2000, many thanks for your explanation.

My working environment looks different.

  • windows 10
  • static installed FF67 with his own profile
  • portable FF67 with his own profile

All other people use the static installed FF. Only i use the portable with PortableApps. Bevore, with FF66, i started the portable version and every link opened a new tab in the running instance.
Now, every link open the static instance. But this, i can't use. I need my portable profile.

Never i have used the ProfileManager. What i have to do to tell the started FF instance with the link, to use the portable profile? I don't like for every link "copy the link address" in a new tab of the browser. It looks like middleage.

In the windows preference menu for browser now i found 2 entries for firefox. Is that correct?

"If you want to open a new tab in an existing instance of Firefox you must launch Firefox in a way that targets the profile for that instance"
Yes, i agree. Now it is necessary. And how can i do that under windows 10 and with links in emails in Tb or in the browser or anywhere?

An explanation of what the current behavior [FF 67] is, what expected behavior is [the two may not be the same], command-line options, explanation of installs.ini... would certainly be nice, because as it is, there is a dearth of information to be found [at least that I have found].

?

The expectation is that whatever mechanism you use to launch Firefox

Prior to 67, I knew what to expect.
With 67, I no longer know?

we select a profile (based on either command line arguments or just using the default for that install)
So a given way of launching Firefox will consistently open the same profile.

There we go again.
What is an "install"?
And with FF 67, I can now also ask, what is "a given way of launching Firefox"?

As it is, what is firefox.exe -p profile1 expected to do?

I used to know what I expected it to do - in all circumstances - in any Mozilla or Mozilla based product.
It did what it did - consistently, in times past.
I've yet to figure out what it does, currently - but most times, it does not open up profile the, profile1 - directly (instead it opens Profile Manager)?

Dear friends, i have a question about "launch Firefox"

The way for external start request is?

  • The system (windows or other) give the control to the default system firefox
  • This firefox use the profiles.ini to select the firefox profile (default or parameter defined)
  • This firefox give the control to this targeted instance (itself or another (running or new started))

Inside of the running firefox it is different. It stays there.

For an answer i would be very thankful.

Dear friends, to complete this bug (?) for my situation, that is different to that of Roman Sąsiada (katoda):

I use now an old tool "register firefox portable" (registerfp) to install a second entry in the registry in Win 10 for all option (type and protocol). With "default program" i can switch between static and portable installed FF67. With that, i have now the same situation like before with the FF66.

many thanks to all and greetings, willi
Asuncion, Paraguay

Another workaround I have found to this bug in Firefox 67+ is editing the registry in Windows.

Assuming FirefoxURL is the default protocol handler for http and https, you can edit HKEY_CLASSES_ROOT\FirefoxURL\shell\open\command and change it to "newhandler.exe" "%1" where newhandler.exe is the location of a compiled AutoHotkey script:

if !(f:=FileOpen("profile1location\parent.lock","r"))
run absolutelocationoffirefox.exe -p profilename1 %1%
else if !(f:=FileOpen("profile2location\parent.lock","r"))
run absolutelocationoffirefox.exe -p profilename2 %1%
else
run absolutelocationoffirefox.exe -p anotherprofile %1%

Perhaps the original poster should have framed it as a security issue instead.

In FF67+, an https: link (in a text file for instance) will now open in a profile of unknown security rather than in the secure profile in use. As two instances in Windows, the new profile will be on the potentially insecure C: drive and will use disk caching.

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

The expectation is that you'd always want launches by other applications to open in the default profile.

I don't understand the logic behind this decision! How it's helping the users now? It was working fine until it's removed.

The expectation is that whatever mechanism you use to launch Firefox we select a profile (based on either command line arguments or just using the default for that install). If that profile is already open in another instance of Firefox then it will just open a new tab in that instance. So a given way of launching Firefox will consistently open the same profile.

Before this, the expectation is that Firefox prioritizes the active/open profile over the default one. At least it could be enabled by a switch like --active-profile.

Hi there, I didn't see this when I filed this duplicate: https://bugzilla.mozilla.org/show_bug.cgi?id=1600989

I'm trying to switch to Firefox from Chrome as my daily driver. I can tell you that Chrome profiles indeed open links from external applications into whatever profile was last active.

Firefox on Fedora Linux and CentOS Linux also open links into the last active profile window, the same way the Chrome works on both Windows and Linux.

I don't think that this should be considered expected behavior--it's deviating from the actual expected behavior established by:

  • Firefox on Linux
  • Chrome on Windows
  • Chrome on Linux

I don't know what kind of engineering resources would go into fixing this, but even if this isn't a high priority, I definitely don't think that this should be considered "resolved."

Flags: needinfo?(dtownsend)

(In reply to Seth Goldin from comment #21)

Hi there, I didn't see this when I filed this duplicate: https://bugzilla.mozilla.org/show_bug.cgi?id=1600989

I'm trying to switch to Firefox from Chrome as my daily driver. I can tell you that Chrome profiles indeed open links from external applications into whatever profile was last active.

The profiles feature in Chrome is quite different to that in Firefox. For example Chrome does not allow you to set a default profile to open. It always, as you say, opens whatever happens to have been the last profile open. I don't see a particular reason why we need to emulate Chrome in this regard.

Firefox on Fedora Linux and CentOS Linux also open links into the last active profile window, the same way the Chrome works on both Windows and Linux.

I just tested on Ubuntu and Firefox behaves as expected there. Please make sure you are using a version of Firefox (ideally built by Mozilla) of version 67 or later. If you still see a difference then please file a bug.

I don't know what kind of engineering resources would go into fixing this, but even if this isn't a high priority, I definitely don't think that this should be considered "resolved."

It is resolved in that the current behaviour is intended and expected.

Flags: needinfo?(dtownsend)

Guys, you keep saying this is intended and expected. I'm thinking either I need to try to implement this and send a PR and be hopeful for a merge or return back to Chromioum. Using open source is all about flexibility and freedom, what's the benefit when others decide to remove something without allowing you to choose? It sounds more like Apple's attitude.

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

(In reply to Seth Goldin from comment #21)

Hi there, I didn't see this when I filed this duplicate: https://bugzilla.mozilla.org/show_bug.cgi?id=1600989

I'm trying to switch to Firefox from Chrome as my daily driver. I can tell you that Chrome profiles indeed open links from external applications into whatever profile was last active.

The profiles feature in Chrome is quite different to that in Firefox. For example Chrome does not allow you to set a default profile to open. It always, as you say, opens whatever happens to have been the last profile open. I don't see a particular reason why we need to emulate Chrome in this regard.

It's a nice and easy way to stay logged into different accounts on the same services, and for Chrome, this is Google's official recommendation: https://support.google.com/chrome/answer/2364824?co=GENIE.Platform%3DDesktop&hl=en

"Profiles are ideal for...keeping your different accounts, like work and personal, separate."

Sometimes you want the incoming links to open into one account or another, but you still want to have the two different profiles open at the same time in different windows. If you are not able to choose into which profile a link will open, this means that any time you want to open a link from an external application into the non-default profile, you have to copy and paste the link. That's annoying and less efficient.

Firefox on Fedora Linux and CentOS Linux also open links into the last active profile window, the same way the Chrome works on both Windows and Linux.

I just tested on Ubuntu and Firefox behaves as expected there. Please make sure you are using a version of Firefox (ideally built by Mozilla) of version 67 or later. If you still see a difference then please file a bug.

I was mistaken. Testing again on Fedora, I hadn't noticed because I was only trying to open links into the default profile. The behavior is the same.

I don't know what kind of engineering resources would go into fixing this, but even if this isn't a high priority, I definitely don't think that this should be considered "resolved."

It is resolved in that the current behaviour is intended and expected.

It seems like on this thread, we're finding that lots of users disagree. Would it be better to file a new, separate ticket that's an RFE rather than a bug? I know that I would love to be able to hit a checkbox somewhere and have Firefox behave as I've described, and it seems like lots of other bug reporters in this thread agree.

(In reply to Seth Goldin from comment #24)

It's a nice and easy way to stay logged into different accounts on the same services, and for Chrome, this is Google's official recommendation: https://support.google.com/chrome/answer/2364824?co=GENIE.Platform%3DDesktop&hl=en

"Profiles are ideal for...keeping your different accounts, like work and personal, separate."

Sometimes you want the incoming links to open into one account or another, but you still want to have the two different profiles open at the same time in different windows. If you are not able to choose into which profile a link will open, this means that any time you want to open a link from an external application into the non-default profile, you have to copy and paste the link. That's annoying and less efficient.

Part of the reason for the current behaviour is that you are always able to know with 100% certainty what profile a link you click on will open in without any other knowledge needed. This is not true for Chrome for example, I need to know what profile I happen to have been using the last time I quit, or which window happens to have been the most recent used in order to know which profile a link will open in. This is in our opinion a better behaviour, but we are well aware that others disagree.

It seems like on this thread, we're finding that lots of users disagree. Would it be better to file a new, separate ticket that's an RFE rather than a bug? I know that I would love to be able to hit a checkbox somewhere and have Firefox behave as I've described, and it seems like lots of other bug reporters in this thread agree.

Bugzilla is not a forum for advocacy, in only rare occasions does it help us understand the prevalence of a problem. As a rule if a bug starts to attract too many "me too" comments we will turn off commenting for the bug because such comments do not help us understand the issue further and only waste developers time by filling their inboxes with unhelpful mail.

Filing an RFE with an actual idea for what we could do that resolves the conflict between predictably opening links and being able to open lionks in a preferred profile might help but there doesn't seem to be a good proposal for how to do that at this time.

(In reply to Amir Karimi from comment #23)

Guys, you keep saying this is intended and expected. I'm thinking either I need to try to implement this and send a PR and be hopeful for a merge or return back to Chromioum. Using open source is all about flexibility and freedom, what's the benefit when others decide to remove something without allowing you to choose? It sounds more like Apple's attitude.

Open source does not mean that we are obligated to make the product in your image (see the no obligation section of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html). If you were to submit a patch that simply switched to opening links in the most recently used profile (though I'm not actually sure how possible that is to implement given the current state of things) then it would be rejected as it breaks the predictable behaviour listed above.

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

Filing an RFE with an actual idea for what we could do that resolves the conflict between predictably opening links and being able to open lionks in a preferred profile might help but there doesn't seem to be a good proposal for how to do that at this time.
Thanks for the explanation. I've gone ahead and filed an RFE: https://bugzilla.mozilla.org/show_bug.cgi?id=1601351

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

Filing an RFE with an actual idea for what we could do that resolves the conflict between predictably opening links and being able to open lionks in a preferred profile might help but there doesn't seem to be a good proposal for how to do that at this time.

Thanks for the explanation. I've gone ahead and filed an RFE: https://bugzilla.mozilla.org/show_bug.cgi?id=1601351

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