It might be worth opening a bug to document your case so it isn't lost. https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=Startup%20and%20Profile%20System
Mike On Wed, Nov 11, 2020 at 8:40 PM Andrew J. Buehler <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2020-11-11 at 10:45, Mike Kaply wrote: > > > When we upgrade or install 64 bit Firefox, if a 32 bit Firefox is > > there, we use the same directory. > > > > So my recommendation would be that you not uninstall and then > > reinstall, but simply install or let the upgrades happen. > > Unfortunately, that would A: leave 64-bit Firefox installed in the > 32-bit program hierarchy, which is undesirable just on general > principles, and B: mean that machines which got a clean install would > have Firefox installed under a different path from machines which got > upgraded, which is undesirable not only from general principles but also > because it would make managing configuration and uninstalls and the like > harder (which path do we need to install distribution\policies.json > under? which path do we need to look under to trigger the uninstall > helper? etc.). > > I can see why people might choose to go this route, but it really does > not sit well with me. > > > Unfortunately Windows didn't make this situation easy. > > - From my perspective, at least at a glance, Windows' contribution to the > situation seems relatively minor. > > It also seems to me as if it shouldn't be too difficult to implement the > behavior I'd prefer within Firefox, relative to the behaviors that > already exist; it just apparently hasn't been done. That's a moot point > for the case at hand, because my organization isn't going to wait for a > new Firefox release before upgrading even if that new release would > include this behavior, but it could still be helpful for others. > > What we'll probably wind up doing is setting the "use legacy profiles" > flag, running with that for a year or three, and then eventually turning > it off and fixing up any broken profiles that get discovered after that > point manually. That's far from ideal, both because of the risk of > having those broken profiles and because we'll be locked out of > profile-per-install for that long, but it's probably the best we're > going to be able to manage. > > I do also still think that a way to explicitly tell Firefox to import a > specific existing profile's contents into the current (new) profile > would be useful, including in other contexts. > > - -- > Andrew J. Buehler > -----BEGIN PGP SIGNATURE----- > > iQJJBAEBCgAzFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAl+soIwVHHdhbmRlcmVy > QGZhc3RtYWlsLmZtAAoJEASpNY00KDJraVEP/RRuTR+MSouftHZ7wdsQcqYkiuBE > sd1VvMXXFqDPWLNXer5qGRH4z9B3Ch7O6Prn7NwIQ0wmJwwgH+d37s+WlYxmLqF6 > /G/UOOX6h8gs7L56iklvRX6gLhmE5LzDKLZL6O+IFU7ZvFBScAEOE87hJiS7viFN > 0kiJ/Xvao+Mf14cNFsKb6uFB8Q1hSbGW4PvDDLyalmjnuRbZqQAk0UcUIYiVkaIp > +vm6DuOndCPGFSdxx0sS+C0zvIgAjhn5UseR85IuZ4riOdUMkbeO1mVQv6v3FJr4 > RQYFJ7MdRBekkEAaLghOLtzZ1PktVmqGz52m7EZczzTZZWQUXzDzuWViMb83LRTd > SIAO16UseX1BRqH9OaGCXE2IenSs5pZ5Asm4gd4dYOmGex1VWSM7XGm9/vuOvmNq > T8XOLklQap18e82JUcIQSXOzlKjXTDI/Aa/EAY2hz8xOUpBPygtNN2f5S9Z4UhzX > vl5DYZzFefDjbb/miHgfg2yp49sIALQ8YvFfP1wZ4bTu7FhOpm7oFpXlJWnHLeN7 > x98CaNVWgomopaN2G7jTXNMFbBvMJwo0YKPtiaiAS+XTeTsfmg+vlrZ7EEwYyfsM > iCl4ZJYn+ofQXhkkVvJLGScke/7meTB1QV5BCeHvAkkbEhptFbvnfhG3W061Ec8+ > fV79OMFqYWZ2e6GA > =bi0X > -----END PGP SIGNATURE----- > _______________________________________________ > Enterprise mailing list > [email protected] > https://mail.mozilla.org/listinfo/enterprise > > To unsubscribe from this list, please visit > https://mail.mozilla.org/listinfo/enterprise or send an email to > [email protected] with a subject of "unsubscribe" >
_______________________________________________ Enterprise mailing list [email protected] https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to [email protected] with a subject of "unsubscribe"
