1535021 - Check if a remote instance is using the default profile before showing the profile manager

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, enhancement)

Description

[Dave Townsend [:mossop]]

Currently when Firefox is configured to show the profile manager on startup we always show it, even if an existing instance is running. This is a change in behaviour from bug 1518639. Looking over the code yesterday I think there is a fairly straightforward way to do default profile selection, then check for a remote instance, then if that fails check the option and show the profile manager in that case.

Comment 1

[Dave Townsend [:mossop]]

Attachment: Bug 1535021: Check if there is an existing instance of Firefox using the default selected profile before showing the profile manager.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/af5b991568da
Check if there is an existing instance of Firefox using the default selected profile before showing the profile manager. r=froydnj

Comment 3

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/af5b991568da

Comment 4

[Bob]

There's a bit of an edge case where the profile manager is shown unexpectedly and different from previous behaviour, but this may be difficult to avoid. It happens when a -no-remote instance/profile is opened after a remote one, and becomes the last-selected.

(on Windows, Firefox 67.0.4)

1. Configure Firefox to show profile manager (untick "use selected without asking")
2. Start an instance of Firefox normally, using default profile
3. Start an instance of Firefox with -no-remote, using test profile
4. Open a URL with system default handler, e.g. start http://google.com in Windows cmd
5. Profile manager shows up, with the -no-remote test selected
6. If default is selected now, the URL opens in the existing instance and future invocations correctly select the last-selected default and open in the existing instance automatically

Previously, this would have defaulted to the one "remote" instance available. Now, it tries for the "last selected" profile, even if that's a -no-remote instance.

One possible way around it that I can see is to maintain a separate "last selected" and "last remote" profile. "last selected" being what is displayed in the profile manager on next launch, including -no-remotes as it currently is, but the profile tried for remoting should not be updated when a new -no-remote instance is launched, i.e. it should only try the last remoting-enabled instance/profile. Perhaps add a new field to installs.ini of DefaultRemote in addition to Default.

It's not a huge issue, and may not be worth the effort to fix, but I'll mention it here because it confused me the first few times I encountered it.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Bob from comment #4)

There's a bit of an edge case where the profile manager is shown unexpectedly and different from previous behaviour, but this may be difficult to avoid. It happens when a -no-remote instance/profile is opened after a remote one, and becomes the last-selected.

(on Windows, Firefox 67.0.4)

1. Configure Firefox to show profile manager (untick "use selected without asking")
2. Start an instance of Firefox normally, using default profile
3. Start an instance of Firefox with -no-remote, using test profile
4. Open a URL with system default handler, e.g. start http://google.com in Windows cmd
5. Profile manager shows up, with the -no-remote test selected

This is because when you choose a profile from the profile manager you are changing the default profile and so changing what profile Firefox will attempt to use by default. Since there is no available remote instance for the test profile we show the profile manager as that is the chosen setting.

Comment 6

[Bob]

Yes, I understand the technical reason it happens. But to a user (who is unaware of the new remote selection algorithm), the additional profile manager prompt is unexpected when the new instance that changed the last/default selection was explicitly declared -no-remote.

I suggested a way to distinguish between the default profile and the last opened remote-enabled instance, but since this is probably a rare use case I don't know if that's a change worth making.

One possible way around it that I can see is to maintain a separate "last selected" and "last remote" profile. "last selected" being what is displayed in the profile manager on next launch, including -no-remotes as it currently is, but the profile tried for remoting should not be updated when a new -no-remote instance is launched, i.e. it should only try the last remoting-enabled instance/profile. Perhaps add a new field to installs.ini of DefaultRemote in addition to Default.