736893 - Profile Manager Remembers Only Last Selected Profile, Not Last Actually Used Profile

Status: NEW

(Toolkit :: Startup and Profile System, defect)

Description

[David E. Ross]

Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 SeaMonkey/2.8

I use multiple profiles.  For this bug report, I'll call them AA, BB, CC, and DD.  I almost always launch SeaMonkey via a Windows shortcut that has
      C:\SeaMonkey2\seamonkey.exe -p AA
(having installed SeaMonkey in its own directory and not in C:\Program Files).  

If I switch my current profile to BB and later terminate SeaMonkey while still in BB, the entry in file profiles.ini for BB contains 
      Default=1
If I then launch SeaMonkey via the Windows shortcut indicated above -- which puts SeaMonkey into profile AA -- the Default=1 remains in the profiles.ini entry for BB and not for AA.  Thus, if I terminate SeaMonkey and another application causes SeaMonkey to launch, it will launch in profile BB even though profile AA was the last one used.  

Either SeaMonkey should have a UI to allow users to designate a preferred default profile that is not changed by the Profile Manager or else SeaMonkey should move Default=1 to the current profile in profiles.ini when launched into a specific profile with the -p parameter.

Comment 1

[therube]

I will confirm that a Profile opened with a command line argument:

> -P "<profile name>"

does not set the the profiles.ini "Default=1" to <profile name>.


Other methods of opening, switching Profiles, does look to set Default.

> -P, with no Profile name given, i.e. Profile Manager opens, sets Default=1

> Tools | Switch Profile..., sets Default=1


That said, & I do use multiple Profiles all the time, I really don't have a problem with the behavior as it is.

About the only time it may lead to confusion, is if you open Profile Manager, it shows the default Profile as shown in profiles.ini, & that could be different from the Profile that is actually in use.

One (I) would expect Profile Manager to be a means to determine which Profile you are using, as other then about:support (which you wouldn't expect an end user to use) there is no other readily available method (which stinks, IMO).

And on that last note, one could say this is indeed a bug (even if it does not bug me).

Comment 2

[David E. Ross]

I have observed this problem in three situations, all of which involve SeaMonkey not running:    

1.  Using an E-mail client that is not Mozilla-based and clicking on a Web link in an E-mail message.  

2.  "Opening" what Microsoft calls an Internet shortcut.  

3.  Having a non-browser application launch SeaMonkey for "further information".  

With all three of these, I get the profile that was last selected via the Profile Manager, not the profile that was last used (generally AA selected via the
           C:\SeaMonkey2\seamonkey.exe -p AA
Windows shortcut).

Comment 3

[[e-mail]]

Normal startup doesn't try to write the last used profile, and I doubt that the toolkit startup module owner would agree to change this.

Comment 4

[Philip Chee]

The profile service is in Toolkit. Moving.

Comment 5

[David E. Ross]

Given bug #214675, is this really a Toolkit bug?

Comment 6

[krs_random]

Firefox 106.0.4
Arch Linux

How to reproduce:

Open a link from a different app or spawn a new tab with

firefox -new-tab mozilla.org

• With multiple Firefox windows open it will always be opened in the last active, focused Firefox window.

• With multiple Firefox windows with different Profiles the tab always opens in the last started Profile.

Problem:

Using a multiple profiles should not result in a change of the behavior where the new tab spawns. The only way to reset it is to open a new window with the profile where the tab should open.
Having different work and private profiles users can't rely on links being opened where one would suspect it.

Solution:

Links should always open in the last active Window, no matter the profile.

Comment 7

[krs_random]

Workaround:

from https://wiki.mozilla.org/Firefox/CommandLineOptions#-no-remote

Using the -no-remote parameter on additional profiles will prevent remote opening of tabs in those profiles

While this helps circumventing the bug it comes with a loss of usability.