Open Bug 1557117 Opened 5 years ago Updated 2 years ago

Profile became inaccessible after update when there are more than one install.

Categories

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

Product:
Toolkit
Component:
Startup and Profile System
Version:
67 Branch
Type:
defect

Tracking

()

People

(Reporter: yoasif, Unassigned)

References

Details

Report of a user on reddit: https://www.reddit.com/r/firefox/comments/bx0y4v/firefox_updated_and_deleted_all_my_addons_and/

User says they used auto-update to update to the newest release. My guess is that they were using 67.

Once they received the update, their installation directory changed from :\Program Files (x86) to C:\Program Files

They claim that they now have two Firefox installation directories.

This then triggered the behavior in bug 1474285, so it looked like their data was lost.

See Also: → 1474285

The updater specifically never updates files outside of the install directory the update is for or moves the install directory. This is more likely an issue with the profile system.

Note: this sounds like the client had two installs which has happened previously without the client knowing it.

Component: Application Update → Startup and Profile System
Summary: Firefox updated to a new application directory, caused profile to become inaccessible → Profile became inaccessible after update.
See Also: → 1557125
See Also: → 1556612
See Also: 1556612 →

As far as the profile part here is concerned, this is the intentional result of bug 1474285.

I'm told that if you use the 64-bit installer that it will by default install Firefox into a different directory than the 32-bit installer would have so this may have been the case here.

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

I'm told that if you use the 64-bit installer that it will by default install Firefox into a different directory than the 32-bit installer would have so this may have been the case here.

Does that mean that moving from 32bit to 64bit Firefox is not supported, or that it is supported only if the new binary is in the same directory as the old binary? Is Firefox still automatically upgrading users to 64bit (I know that this happened at some point)?

In any case, this support document likely needs to be changed to clarify that while user data will not be removed, it will become inaccessible without additional work: https://support.mozilla.org/en-US/kb/switch-32-bit-64-bit

(In reply to Asif Youssuff from comment #3)

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

I'm told that if you use the 64-bit installer that it will by default install Firefox into a different directory than the 32-bit installer would have so this may have been the case here.

Does that mean that moving from 32bit to 64bit Firefox is not supported, or that it is supported only if the new binary is in the same directory as the old binary? Is Firefox still automatically upgrading users to 64bit (I know that this happened at some point)?

In relation to app update, when it migrates a client from 32 bit to 64 bit it uses the same install directory.

Yeah -- so I don't understand what happened to this user - I don't have any real reason to believe that they are lying, and they claim this happened after an app update, not via a self-downloaded installer. :/

I've had a few bug reports where the client didn't realize that they had multiple installations.

I should mention one case where they were using a shortcut to launch one install and the other install was set as the default which caused quite a lot of confusion until we discovered that there were two installs.

edit There was no lying involved in any of the reports... just a lack of knowledge that there were more than one install

(In reply to Robert Strong (Robert they/them) [:rstrong] (use needinfo to contact me) from comment #7)

I should mention one case where they were using a shortcut to launch one install and the other install was set as the default which caused quite a lot of confusion until we discovered that there were two installs.

edit There was no lying involved in any of the reports just a lack of knowledge that there were more than one install

I DM'ed Asif on Reddit to confirm it, I'm the one who created the thread and I can confirm that I indeed had two installs, here is part of the text from my reply explaining it:

"At first, I thought that this was not the case, but I have now figured out that the shortcut on the start menu is to the C:\Program Files version while the one on the taskbar was to the C:\Program Files (x86) indeed.

Sorry, I didn't realize I had two installs... I don't really know how that happened if I'm being honest"

Hi Alan, I've also had difficulty figuring out which install is which on my systems and there is absolutely no reason for you to be sorry.

Hi Matt, awhile back I considered a few things that could be done with Windows shortcuts so clients can more easily figure out that they have more than one install such as if there is already an install either offering to uninstall the other one (wouldn't work well with a no interaction stub installer) or automatically naming the shortcuts differently. Are there any plans to make this situation better?

Flags: needinfo?(mhowell)
Summary: Profile became inaccessible after update. → Profile became inaccessible after update when there are more than one install.

Hmm. My first thought would be to use the shortcut comment field, but there's no way to make that appear in the start menu, so I think it has to be something in the name. But I'm not sure what we could put there that would help this situation; we could put (part of) the install path, the architecture, the version, or all of the above in the shortcut name, but I don't know if seeing any of that would really do anything to lead a user who's confused about "losing" their profile toward figuring out what's going on. Also renaming existing shortcuts scares me, because I've had to do it before and it made a mess.

I wonder if rather than offering to remove an existing install of a different architecture, we should just go back to defaulting to overwriting ("upgrading") them. The rationale for bug 1120124 was that doing a 64-bit installation in Program Files (x86) was confusing, but now that the updater creates that situation intentionally, maybe having the installer check the architecture is doing more harm than good. Most people don't actually want to have multiple architectures installed. Also, not saying we shouldn't offer to uninstall existing copies under other circumstances, but in this case I think the most helpful thing is to just make the default make sense.

Flags: needinfo?(mhowell)

(In reply to Matt Howell (he/him) [:mhowell] from comment #10)

Hmm. My first thought would be to use the shortcut comment field, but there's no way to make that appear in the start menu, so I think it has to be something in the name. But I'm not sure what we could put there that would help this situation; we could put (part of) the install path, the architecture, the version, or all of the above in the shortcut name, but I don't know if seeing any of that would really do anything to lead a user who's confused about "losing" their profile toward figuring out what's going on. Also renaming existing shortcuts scares me, because I've had to do it before and it made a mess.

I'm not suggesting renaming shortcuts. I am suggesting that on install not overwriting existing shortcuts and create some type of naming so the client has at least a clue that they have more than one install along with a more descriptive name for the shortcut if possible.

I wonder if rather than offering to remove an existing install of a different architecture, we should just go back to defaulting to overwriting ("upgrading") them. The rationale for bug 1120124 was that doing a 64-bit installation in Program Files (x86) was confusing, but now that the updater creates that situation intentionally, maybe having the installer check the architecture is doing more harm than good. Most people don't actually want to have multiple architectures installed. Also, not saying we shouldn't offer to uninstall existing copies under other circumstances, but in this case I think the most helpful thing is to just make the default make sense.

That might very well be an improvement. iirc the migration from 32 bit to 64 bit is no longer being served by balrog.

(In reply to Robert Strong (Robert they/them) [:rstrong] (use needinfo to contact me) from comment #11)

I'm not suggesting renaming shortcuts. I am suggesting that on install not overwriting existing shortcuts and create some type of naming so the client has at least a clue that they have more than one install along with a more descriptive name for the shortcut if possible.

Sorry, misinterpreted there. I'm still not certain what we could put in the shortcut name that would be helpful. Open to suggestions.

That might very well be an improvement. iirc the migration from 32 bit to 64 bit is no longer being served by balrog.

I'll go ahead and file this one.

(In reply to Matt Howell (he/him) [:mhowell] from comment #12)

(In reply to Robert Strong (Robert they/them) [:rstrong] (use needinfo to contact me) from comment #11)

I'm not suggesting renaming shortcuts. I am suggesting that on install not overwriting existing shortcuts and create some type of naming so the client has at least a clue that they have more than one install along with a more descriptive name for the shortcut if possible.

Sorry, misinterpreted there. I'm still not certain what we could put in the shortcut name that would be helpful. Open to suggestions.

I'm thinking that this comes up enough that not letting perfect be the enemy of good or more likely better than the current state so naming it just about anything would be better than where we are now. Also, the clients that only have one installation which should be the majority won't have additional shortcuts. With the recent changes to how profiles are handled along with this bug I think even just appending a number would be better than where we are now.

Blocks: 1557125
See Also: 1557125 →

Per the support document I linked earlier: https://support.mozilla.org/en-US/kb/switch-32-bit-64-bit

We recommend that users uninstall 32bit Firefox and install 64bit Firefox. I don't think bug 1558320 fixes the issue where the installer will default to a new Firefox directory if they remove their old install, unless I misunderstand what bug 1558320 does.

Priority: -- → P3

(In reply to Asif Youssuff from comment #3)

In any case, this support document likely needs to be changed to clarify that while user data will not be removed, it will become inaccessible without additional work: https://support.mozilla.org/en-US/kb/switch-32-bit-64-bit

Related discussion:
https://support.mozilla.org/en-US/kb/switch-32-bit-64-bit/discuss/8010 Archive or update? (see bug 1557117)

Another article, https://support.mozilla.org/en-US/kb/how-do-i-tell-if-32-bit-or-64-bit includes a note under the "Windows program listing" section about possibly having both 32-bit and 64-bit versions of Firefox installed. I added information about dedicated profiles and how to switch profiles, in this revision: https://support.mozilla.org/en-US/kb/how-do-i-tell-if-32-bit-or-64-bit/revision/183674
The note now links to https://support.mozilla.org/en-US/kb/dedicated-profiles-firefox-installation and https://support.mozilla.org/en-US/kb/recover-user-data-missing-after-firefox-update

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