Closed Bug 1535021 Opened 6 months ago Closed 6 months ago

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

Categories

(Toolkit :: Startup and Profile System, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox67 --- fixed

People

(Reporter: mossop, Assigned: mossop)

References

Details

Attachments

(1 file)

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.

Blocks: 1518639
Pushed by dtownsend@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

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.

(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.

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.

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