1714904 - Win10 with Roaming Profiles: Firefox creates new profiles when Updated

Status: UNCONFIRMED

(Toolkit :: Startup and Profile System, defect)

Description

[Jobst Schmalenbach]

Attachment: mozilla2.png

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

Steps to reproduce:

We use Windows (10) Roaming Profiles so users can switch/share workstations, e.g. special workstations for conferencing. %APPDATA% is located on a NETWORK device (samba share, home), thus Firefox's Profile directory is located there, too. When switching computers files/desktop/email/startup/icons/everything is available as it should, it has been working for decades.

Since about a year Firefox has a MASSIVE (deal breaker) problem when switching machines. When a user has worked for a couple of days on the first machine with Firefox being updated while using it, the user then logs out of that machine closing everything properly, switches computers and Firefox has NOT been updated on THAT machine the user looses the PROFILE as Firefox comes up "You are using an incorrect profile, exit or create a new profile".

Even copying the profile from a backup that was created AFTER the upgrade does not help, Firefox will NOT accept this.

Even letting Firefox updating itself, then close it, copy the profile from a backup that was created JUST after the user logs out of the first machine, then restart Firefox ... Firefox will complain.

When the user then moves back to the FIRST machine, all is fine.

Actual results:

We are using Windows 10 ROAMING profiles located on a NETWORK share pointed to by %APPDATA% were the Firefox profiles are stored, too.
1: User works for days on first machine.
2: Firefox is being updated to latest version on THAT machine
3: user keeps using Firefox with profile intact.
4: user closes Firefox and ALL other apps
5: user logs out
6: user switches machines, this machine does NOT have the latest version of firefox as it had not been used for a day
7: user logs in and starts Firefox
8: Firefox complains about PROFILE mismatch and wants the user to a) exit or b) create a NEW PROFILE - NO OTHER OPTION!

Expected results:

There are a couple of options:

1. Firefox SHOULD on startup update itself, then restart. Upon restart Firefox should realise the LATEST profile version is already being used (as it was updated when using the first computer) and let the user keep working.
2. Firefox should have a simple option JUST to update itself without even touching/querying the users profile, then upon start the profile is already updated.

I have really no idea why this SHOULD ever be a problem.
From my (or the users) point of view nothing has changed:

1. user uses Firefox on first computer with LATEST version of firefox
2. user logs out an goes to the NEXT computer
3. user logs into the next computer (Note that %APPDATA% is still the same), Firefox updates and then realises "oh this already is the lastest profile, nothing to do" and just keeps working

I have no problems with any of the other browsers, Chrome is quite happy to use its (shared) "z:\Google\Chrome", constantly updating itself.

I have attached an image of the %APPDATA% Profile dir

Firefox's Profile profile.ini file content:
[Install308046B0AF4A39CB]
Default=Profiles/rcbzteqe.default-release
Locked=1
[Profile1]
Name=default
IsRelative=1
Path=Profiles/6elvqs6z.default
Default=1
[Profile0]
Name=default-release
IsRelative=1
Path=Profiles/rcbzteqe.default-release
[General]
StartWithLastProfile=1
Version=2

Comment 1

[Dave Townsend [:mossop]]

The version downgrade check was implemented because we simply cannot keep profile data backwards compatible with earlier versions of Firefox without really hampering our ability to make changes. In most cases this warning only shows if you accidentally run the wrong version of Firefox on your computer (you might have release and beta builds installed for example) or if you have manually installed an older version. Your case however is different though and outside of the general user's control so I can see why it is a bigger problem.

(In reply to Jobst Schmalenbach from comment #0)

1. Firefox SHOULD on startup update itself, then restart. Upon restart Firefox should realise the LATEST profile version is already being used (as it was updated when using the first computer) and let the user keep working.

We can't check for updates on every startup unfortunately. It would incur a massive performance cost that we simply could not accept. However we could potentially do it when we detect this kind of downgrade scenario, a slower startup is fine if that startup is only going to result in an annoying dialog anyway. I filed bug 1715125 about this, though I will be honest it would not be trivial to implement in this way so I don't know that it is something we would invest time in. However...

2. Firefox should have a simple option JUST to update itself without even touching/querying the users profile, then upon start the profile is already updated.

Version 89 which rolled out a few days ago now includes a background update system which will attempt to keep Firefox updated even when Firefox isn't run. It has no reliance on the user's profile. Still not ideal as it relies on the computer running for a time before Firefox is launched.

I have no problems with any of the other browsers, Chrome is quite happy to use its (shared) "z:\Google\Chrome", constantly updating itself.

So just to be clear you have Chrome installed on a network drive and so all machines see the newest version? Is there a reason you don't do that with Firefox?

Comment 2

[Jobst Schmalenbach]

Going to answer in reverse order from above ....

1. Chrome, like Firefox, is installed on each computer (I use Ninite PRO when creating a new machine, not big enough for server based methods).
   I am using the two Google based Profile settings to have the data on a network drive, but cache LOCAL.

   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\DiskCacheDir is set to %LOCALAPPDATA%
   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\UserDataDir is set to %HOME%\Google\Chrome

This does work for Chrome, they must do their updates differently.

2. You wrote "do it when we detect this kind of downgrade scenario, a slower startup is fine if that startup is only going to result in an annoying dialog anyway." - the dialog box is there anyway/already!
   All you have to provide is another option "Update Firefox Now" on that dialog box to the existing ones (exit, create new profile) and all will be good! The "update" mechanism is there already (from Options -> Help -> About Firefox -> Update) so you could use that?

Comment 3

[Jobst Schmalenbach]

Sorry the formatting was not what I expected ... I forgot the numbering indents ....

Comment 4

[Dave Townsend [:mossop]]

(In reply to Jobst Schmalenbach from comment #2)

All you have to provide is another option "Update Firefox Now" on that dialog box to the existing ones (exit, create new profile) and all will be good! The "update" mechanism is there already (from Options -> Help -> About Firefox -> Update) so you could use that?

It is unfortunately not that simple. The built in update system was built to work when Firefox is already started and requires various things to be available including a user profile. At the time this dialog is shown most of Firefox's core services are unavailable, it's a bit of a hack to even get the dialog to show at that point.

I believe that most companies doing this sort of thing deploy Firefox themselves rather than let Firefox automatically update, Mike has more experience here though so he may have advice.

Comment 5

[Mike Kaply [:mkaply]]

As Dan said, most people in this situation update Firefox themselves.

My suggestions would be to either set the environment variable MOZ_ALLOW_DOWNGRADE company wide and just trust that most of the time the profiles will be OK or start Firefox with --allow-downgrade parameter.