1587067 - Upgrade from TB 60.9 ESR 32bit to TB 68.1 ESR 64bit creates a new profile

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Jorg K (CEST = GMT+2)]

Remove all traces of previous FF installations from your machine.
Install FF 60.9 ESR 32bit into C:\Program Files (x86)\Mozilla Firefox. Run it.
Make some changes to the profile, so you'd recognise it later, in fact not necessary.

Install FF 68.1 ESR 64bit into C:\Program Files\Mozilla Firefox. Run it.
You're greeted with
"This installation of Firefox has a new profile."

That's caused by the new "profile per install" feature, but I don't really think this is desired. All the user has done is to install a fresh version and they'd expect their profile to be used.

Anyway, we can s/Firefox/Thunderbird/ and move the bug to the Thunderbird queue.

Comment 1

[Jorg K (CEST = GMT+2)]

From my experiments with Thunderbird I think I can say that if any version of FF 68.1 ESR, so 32bit or 64bit, had been installed into C:\Program Files (x86), the profile would have been recognised. So not recognising it based on a new install location seems like a bug and not related to "profile protection" since the 68 version would have made irrevocable changes to the profile regardless of its install location.

Comment 2

[Dave Townsend [:mossop] (PTO until Aug 21st)]

This is essentially a dupe of bug 1580770. Feel free to keep this open if you want to do something on the Thunderbird side.

Comment 3

[Jorg K (CEST = GMT+2)]

Yes, same scenario in bug 1580770 which you made WONTFIX. So what could be done about this? Any hints?

Comment 4

[Dave Townsend [:mossop] (PTO until Aug 21st)]

(In reply to Jorg K (GMT+2) from comment #3)

Yes, same scenario in bug 1580770 which you made WONTFIX. So what could be done about this? Any hints?

You would need to adjust the logic in here somewhere: https://searchfox.org/mozilla-central/source/toolkit/profile/nsToolkitProfileService.cpp#516

Comment 5

[Jorg K (CEST = GMT+2)]

Well, observed behaviour is that any version (32bit or 64bit) installed in the original 32bit-x86 location finds the existing only profile. Only a version installed elsewhere, like in the "native" 64bit non-x86 location rejects the profile.

Is it fair to assume that on first run of TB/FF 68 coming from TB/FF 60 this code doesn't run at all since no installs are found yet?
https://searchfox.org/mozilla-central/rev/17756e2a5c180d980a4b08d99f8cc0c97290ae8d/toolkit/profile/nsToolkitProfileService.cpp#537-570

So it should use the only found profile, no? But it doesn't. So is the issue in the early return here?
https://searchfox.org/mozilla-central/rev/17756e2a5c180d980a4b08d99f8cc0c97290ae8d/toolkit/profile/nsToolkitProfileService.cpp#522

I can't see where the install location or the 32-vs-64-bitness are checked. Which is the final comparison that rejects the profile?

Also, if it were a small fix, I don't quite understand why bug 1580770 wasn't fixed. Sure, there's a workaround, but I think a group of users, especially now the ESR users being upgraded from FF 60 to FF 68 may want to kick the 64bit binary from the 32bit-x86-location and will be surprised to lose their profile.

Comment 6

[Dave Townsend [:mossop] (PTO until Aug 21st)]

(In reply to Jorg K (GMT+2) from comment #5)

Well, observed behaviour is that any version (32bit or 64bit) installed in the original 32bit-x86 location finds the existing only profile. Only a version installed elsewhere, like in the "native" 64bit non-x86 location rejects the profile.

That is correct. We consider that to be a new install as it is in a different location than the last build to use the profile.

Is it fair to assume that on first run of TB/FF 68 coming from TB/FF 60 this code doesn't run at all since no installs are found yet?
https://searchfox.org/mozilla-central/rev/17756e2a5c180d980a4b08d99f8cc0c97290ae8d/toolkit/profile/nsToolkitProfileService.cpp#537-570

Yes

So it should use the only found profile, no? But it doesn't. So is the issue in the early return here?
https://searchfox.org/mozilla-central/rev/17756e2a5c180d980a4b08d99f8cc0c97290ae8d/toolkit/profile/nsToolkitProfileService.cpp#522

That is the function that identifies this as a different install and so rejects using the existing profile.

I can't see where the install location or the 32-vs-64-bitness are checked. Which is the final comparison that rejects the profile?

It is checked here: https://searchfox.org/mozilla-central/rev/17756e2a5c180d980a4b08d99f8cc0c97290ae8d/toolkit/profile/nsToolkitProfileService.cpp#474-491

Also, if it were a small fix, I don't quite understand why bug 1580770 wasn't fixed. Sure, there's a workaround, but I think a group of users, especially now the ESR users being upgraded from FF 60 to FF 68 may want to kick the 64bit binary from the 32bit-x86-location and will be surprised to lose their profile.

I'm not totally sure that it is a small fix. This entire feature turned out to be horrendously difficult to implement and even after months of work we knew that it wasn't going to work perfectly for everyone. This is one case we didn't spot until well after it had hit the release channel, at which point users bit by it had already been dumped into a new profile, there was little benefit to be had to making the system even more complicated for the minority of folks who might get affected in the future.

Comment 7

[Jorg K (CEST = GMT+2)]

Thanks for the comment. I put a whole lot of debug into IsProfileForCurrentInstall() and MaybeMakeDefaultDedicatedProfile() and the result is this as we already suspected: MaybeMakeDefaultDedicatedProfile() returns early after calling IsProfileForCurrentInstall(). That function runs through to the end and returns the value of equal from here greDir->Equals(currentGreDir, &equal).

The path of greDir is "C:\Program Files (x86)\Mozilla Thunderbird" and the path of currentGreDir is "C:\Program Files\Mozilla Thunderbird".

So I suggest to apply the same trick we already added in bug 1583129.

Comment 8

[Jorg K (CEST = GMT+2)]

Attachment: Bug 1587067 - Don't distinguish between 32bit and 64bit install location in IsProfileForCurrentInstall(). r=mossop

Comment 9

[Jorg K (CEST = GMT+2)]

Dave, could you please take a look at the patch, it's mostly the same code as added in bug 1583129. We'd like to ship TB 68.2 next week and need to include a fix for the 32/64 bit issue since we plan to upgrade our users from the previous ESR version TB 60.

Comment 10

[Jorg K (CEST = GMT+2)]

Thanks, Dave.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7c59ec30b84c
Don't distinguish between 32bit and 64bit install location in IsProfileForCurrentInstall(). r=mossop

Comment 12

[Jorg K (CEST = GMT+2)]

Let's change this to sound more like a Thunderbird bug since the change is only for TB.

Comment 13

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/7c59ec30b84c

Comment 14

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/618d630cbad873349f0763b5289509487aaa90fe on THUNDERBIRD_68_VERBRANCH

Comment 15

[Jorg K (CEST = GMT+2)]

Installed TB 60.9 ESR 32bit into C:\Program Files (x86)\Mozilla Thunderbird. Ran it, created a profile.
Installed TB 68.2.0 ESR 64bit into C:\Program Files\Mozilla Thunderbird. Ran it, profile recognised.

Comment 16

[Jorg K (CEST = GMT+2)]

Dave, I've had a case where someone was upgrading from TB 60 x64 to TB 68 x64 and the profile was not recognised. That was on a Spanish system, Spanish Windows and Spanish TB. Does the greDIr here:
https://hg.mozilla.org/mozilla-central/rev/7c59ec30b84c#l1.15
get returned localised? The SHGetKnownFolderPath() paths are non-localised, right?

Another case was reported in bug 1593448 and judging by the reporter's name, the might also have been on a non-English system.

Alice, can you please do the following experiment for us on a Japanese system:

• Rename C:\Users\your-user\AppData\Roaming\Thunderbird to C:\Users\your-user\AppData\Roaming\Thunderbird-good so that it looks like you never had any TB profile. Rename it back after the experiment.
• Install the Japanese x64 version of 60.9.0 on your system into the standard location C:\Program Files\Mozilla Thunderbird.
• Run it, create some "content" in the profile that can be recognised later, like enable the menu bar, set up an e-mail account or just a feeds account (that's faster).
• The do an auto-update via Help > About. If that doesn't work, download the Japanese x64 version of TB 68.2.1 and run it.

Big question: Does the profile you set up get used or do you get prompted to set up a new profile.

I did the experiment on an English system and all was fine. Well, I didn't use auto-update, I used a downloaded version.

Comment 17

[Alice0775 White]

I tested
Steps

1. Start Windows10 64bit Japanese edition on VMWare (no TB installed yet)
2. Install TB60.9 64bit ja build with default settings and launch TB
   https://archive.mozilla.org/pub/thunderbird/releases/60.9.0/win64/ja/Thunderbird%20Setup%2060.9.0.exe
3. Setup an email account and enable Menubar
4. Update via Help > About, then restart

Actual Results:
TB68 starts with new empty user profile(***.default-release) instead of existing profile(***.default) without any prompt.

Comment 18

[Alice0775 White]

Also Reproduced : update from TB60.9 64bit en-US build on Windows10 64bit Japanese edition.

Comment 19

[Jorg K (CEST = GMT+2)]

Thanks, Alice. Just for the record: I've just updated a German 32 bit version on German Windows with no issue.

Comment 20

[Jorg K (CEST = GMT+2)]

Looks like 64 bit upgrades got messed up in this bug. I filed a follow-up in bug 1593540.

Comment 21

[Dave Townsend [:mossop] (PTO until Aug 21st)]

(In reply to Jorg K (GMT+2) from comment #16)

Dave, I've had a case where someone was upgrading from TB 60 x64 to TB 68 x64 and the profile was not recognised. That was on a Spanish system, Spanish Windows and Spanish TB. Does the greDIr here:
https://hg.mozilla.org/mozilla-central/rev/7c59ec30b84c#l1.15
get returned localised? The SHGetKnownFolderPath() paths are non-localised, right?

What that returns is just what the GRE dir actually is, localized or not. SHGetKnownFolderPath should return localized named for the paths.