Why don't we just turn off MOZ_BLOCK_PROFILE_DOWNGRADE?

Matt Harris 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.

Matt

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.
>
> John
>
>
>
> Am 04.07.2019 um 18:51 schrieb Jacques Angevelle:
>> Hi,
>>
>>  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.
>>
>> Jacques
>>
>>
>> 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.
>>>>
>>>> Ben
>>>>
>>>> _______________________________________________
>>>> tb-planning mailing list
>>>> tb-planning at mozilla.org
>>>> https://mail.mozilla.org/listinfo/tb-planning
>>>>
>>> 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 
>>> version
>>> 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
>> https://mail.mozilla.org/listinfo/tb-planning
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning


-- 
“Against stupidity the gods themselves contend in vain.” /― Friedrich 
von Schiller, Die Jungfrau von Orleans /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190705/6f20daea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20190705/6f20daea/attachment.p7s>


More information about the tb-planning mailing list