Why don't we just turn off MOZ_BLOCK_PROFILE_DOWNGRADE?
unicorn.consulting at gmail.com
Fri Jul 5 00:37:23 UTC 2019
A commendable idea, but a quick look at my profile suggests it takes
windows some 3 minutes to tell me it is 29.9Gb in size and has 230,223
files in it. That is without the mozEML files that we routinely also
have in Windows installs. I manually deleted well over 100,000 of those
when I turned to option off.
So do we want to add such a lengthy time to "updates"? If it takes 3
minutes to identify them I assume the backup will be excruciatingly
slow. 30Gb of data is always going to be slow going.
Having said that, there is a very real need for an inbuilt profile
backup and restore, and user demand for such an option. But I think it
needs to be a user accessible option with scheduling, not something we
try and put into the update process. Think migration to a new device as
well as just backup.
On 05-Jul-19 3:33 AM, John Bieling wrote:
> I really think TB should automatically backup a user profile, when it
> gets access by a higher major version number for the first time. So in
> the current situation, after the user updated to TB68.
> If the user later returns to TB60, he will get the error message about
> not being able to access his profile (as it was modified by TB68) and
> instead of suggesting to create a new profile, just allow him to switch
> to the backuped version of his TB60 profile.
> Am 04.07.2019 um 18:51 schrieb Jacques Angevelle:
>> From user's point of view, I think downgrading is nearly mandatory. New
>> versions are often broking add-ons a user can consider essential for his
>> daily use and new dev. policy disabling number of add-ons is really hard
>> to accept. The alternative could be difficult to implement : warn before
>> installation about ALL disabled add-ons with the new version. Backing up
>> all the profile is a solution but I doubt users will do this before each
>> upgrade. The main repercussion should be that users will stop upgrading
>> TB and this is a real security hole.
>> Le 04/07/2019 à 09:30, Nomis101 🐝 a écrit :
>>> Am 04.07.19 um 02:59 schrieb Ben Bucksch:
>>>> Mark Banner wrote on 02.07.19 13:31:
>>>>> was once basically "downgrades are nice but not really supported" is
>>>>> now a definite "downgrades are not supported"
>>>> FWIW, downgrades have always works. I've moved between versions of
>>>> Firefox since decades. I've never ever had any notable corruption
>>>> (modulo very very rare bugs like bug 1530660 which were then fixed).
>>>> This is definitely new and very inconvenient for development, of which
>>>> testing (also with real data and old time-battered profiles) is an
>>>> integral part.
>>>> tb-planning mailing list
>>>> tb-planning at mozilla.org
>>> I see this exacly the same. I never found any problem while
>>> downgrading Thunderbird. The first real issue after downgrading I ever
>>> had was MOZ_BLOCK_PROFILE_DOWNGRADE. For a test I downgraded from TB
>>> 68 to 60 and even to 45.8, but could't see anything broken.
>>> For beta testing and regression finding you often have to downgrade,
>>> which is now very frustrating. And it also happens very often
>>> that a normal user is downgrading. I'm in a Mac user forum and a lot
>>> of support questions there are regarding downgrading to an older
>>> of any given software (because of dislike the new UI, missing
>>> features in the new version or whataver reason). For my oppinionen
>>> MOZ_BLOCK_PROFILE_DOWNGRADE will give a lot of support questions an
>>> a lot of angry users. At least we should give the users a possibility
>>> to switch MOZ_BLOCK_PROFILE_DOWNGRADE off by there own risk and
>>> defenitely warn the user before launching the new version, that he
>>> would not be able to downgrade afterwards.
>> tb-planning mailing list
>> tb-planning at mozilla.org
> tb-planning mailing list
> tb-planning at mozilla.org
“Against stupidity the gods themselves contend in vain.” /― Friedrich
von Schiller, Die Jungfrau von Orleans /
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning