Open Bug 1543414 Opened 5 years ago Updated 1 year ago

[Dedicated Profiles]Two separate installs are using the same dedicated profile when forced by profile manager

Categories

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

Desktop
Windows 10
defect

Tracking

()

Tracking Status
firefox66 --- unaffected
firefox67 --- affected
firefox68 --- affected

People

(Reporter: cbaica, Unassigned)

Details

Attachments

(3 files)

Attached file profiles.ini

[Affected versions]:

  • Fx 67.0b9
  • Fx68.0a1

[Affected platforms]:

  • Windows 10 x64
  • Ubuntu 16.04

[Steps to reproduce]:

  1. Install Firefox in 2 separate locations.
  2. Go to location 1 and launch Firefox by double clicking it.
  3. Go to location 2 and open Firefox with profile manager.
  4. Choose the profile that is in use by Firefox from location 1 and start Firefox .
  5. Close all the Firefox instances that are running.
  6. Open Firefox from location 2 by double clicking it and check the about:profiles page.

[Expected result]:

  • A new profile 'default-beta-1' is created and in use.

[Actual result]:

  • The 'default-beta' profile is in use.

[Regression range]:

  • This does not look like a recent regression as it occurs in the last Fx67.0a1 nightly build as well.

[Additional notes]:

  • In the profile.ini file, the separate builds are locked on the same profile as well (see attachment).
  • This issue does not occur on macOS. There the user is prompted with an error when he tries to launch the second build using the same profile.

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #0)

[Expected result]:

  • A new profile 'default-beta-1' is created and in use.

It's not entirely clear to me that this should be the expected result. The user made a choice to use a particular profile so I don't know if we should change that.

[Regression range]:

  • This does not look like a recent regression as it occurs in the last Fx67.0a1 nightly build as well.

No, we never really figured out what to do in this situation.

  • This issue does not occur on macOS. There the user is prompted with an error when he tries to launch the second build using the same profile.

Huh, that's surprising. Or is this just because of bug 1542316?

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

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #0)

[Expected result]:

  • A new profile 'default-beta-1' is created and in use.

It's not entirely clear to me that this should be the expected result. The user made a choice to use a particular profile so I don't know if we should change that.

From the discussions I had with Adrian F, because of the fixes done to 1533677 and 1535021 Firefox looks at the fact that it already has a process running with the 'default-beta' profile and it just multiplies that process. There would be no reason for the second install to lock on the 'default-beta' profile. So when that second install is started without being forced to use a specific profile, it should read the fact that 'default-beta' is already dedicated for another install and create 'default-beta-1' as its main profile.

[Regression range]:

  • This does not look like a recent regression as it occurs in the last Fx67.0a1 nightly build as well.

No, we never really figured out what to do in this situation.

A good approach would be to have the same behavior on all OS's. Meaning we either take out the alert prompt on mac and we accept the fact that 2 separate installs that have the dedicated profile feature can use the same profile. Or we implement the alert prompt on Windows and Ubuntu as well so this scenario is never reached.

  • This issue does not occur on macOS. There the user is prompted with an error when he tries to launch the second build using the same profile.

Huh, that's surprising. Or is this just because of bug 1542316?

The issues might be related, but I can't tell for sure. What I am certain though, is that on mac, it is impossible to recreate the scenario because of the alert prompt received.

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #2)

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

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #0)

[Expected result]:

  • A new profile 'default-beta-1' is created and in use.

It's not entirely clear to me that this should be the expected result. The user made a choice to use a particular profile so I don't know if we should change that.

From the discussions I had with Adrian F, because of the fixes done to 1533677 and 1535021 Firefox looks at the fact that it already has a process running with the 'default-beta' profile and it just multiplies that process. There would be no reason for the second install to lock on the 'default-beta' profile. So when that second install is started without being forced to use a specific profile, it should read the fact that 'default-beta' is already dedicated for another install and create 'default-beta-1' as its main profile.

This only happens if the install doesn't yet have a default dedicated profile assigned. Step 4 of the STR assigns the profile selected as the default for location 2.

  • This issue does not occur on macOS. There the user is prompted with an error when he tries to launch the second build using the same profile.

Huh, that's surprising. Or is this just because of bug 1542316?

The issues might be related, but I can't tell for sure. What I am certain though, is that on mac, it is impossible to recreate the scenario because of the alert prompt received.

What is the exact error seen?

Attached image macOS prompt

This is the prompt received on macOS when trying to launch 2 separate builds with the same profile.

Ok I think I have figured out what is going on here.

[Steps to reproduce]:

  1. Install Firefox in 2 separate locations.
  2. Go to location 1 and launch Firefox by double clicking it.
  3. Go to location 2 and open Firefox with profile manager.
  4. Choose the profile that is in use by Firefox from location 1 and start Firefox.

At this point because instance 1 is still running with the profile that instance 2 wants to use, instance 2 just tells instance 1 to open a new window and then exits. So there should be only one instance open after this. Except on OSX, where this kind of remoting wasn't supported until bug 469990 was implemented.

I can see an argument that since instance 2 simply deferred to instance 1 here then setting the default for instance 2 may not make sense. That would be quite challenging to change unfortunately.

My impression is that this is a rare enough edge case that it probably shouldn't block. Ultimately I think this is Romain's call.

Flags: needinfo?(rtestard)

At this point because instance 1 is still running with the profile that instance 2 wants to use, instance 2 just tells instance 1 to open a new window and then exits. So there should be only one instance open after this. Except on OSX, where this kind of remoting wasn't supported until bug 469990 was implemented.

I can see an argument that since instance 2 simply deferred to instance 1 here then setting the default for instance 2 may not make sense. That would be quite challenging to change unfortunately.

My impression is that this is a rare enough edge case that it probably shouldn't block. Ultimately I think this is Romain's call.
I agree, the likelihood is tiny (you'd have to install Firefox with the full installer, set a custom install path and launch Firefox with the profile manager in the case that installs 2 doesn't yet have a default dedicated profile assigned) and the impact is small (the browser can be used, the user can set install 2 to a different profile through the profile manager if wanted) so I agree this should not block.

So we will not proceed with this as a blocker, but the issue still needs to be fixed in one way or another.
Either we revert back to an old behavior (where 2 instances can't run with the same profile so an error is received - see attachment), which in my opinion would be best, either we come up with a way to tell Fx that the profile is already locked on an install and should automatically increment the profile name.

Flags: needinfo?(rtestard)
Priority: -- → P2

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: