Why don't we just turn off MOZ_BLOCK_PROFILE_DOWNGRADE?

Jörg Knobloch jorgk at jorgk.com
Tue Jul 2 19:35:58 UTC 2019


Here's my potentially very unpopular view.

This is a non-issue.

90% of user don't use add-ons, they will upgrade from 60 to 68 when it's 
ready and not notice a thing.

Of the remaining 10%, most will use the top-ten/twenty add-ons, and if 
we get that right, they will just get updated automatically.

Going back from 68 to 60 is also a non-issue since 60 doesn't check.

That leaves 0.001% of users, the very vocal ones, how jump between, 
maybe Daily and or beta NN (NN>68) to ESR 68. Those are the ones who 
will have a problem, and they might as well force the downgrade if we 
tell them how.

So far I haven't heard anyone say "we must disable a downgrade since we 
already know that things will break". So unless someone does that 
research, there's nothing to worry about. Sure, the Mozilla platform 
constantly changes of what is in the profile, the structure of the SQL 
databases, security databases, xulstore, etc.

TB also does it's own upgrading of profile data in 
https://searchfox.org/comm-central/source/mail/base/modules/MailMigrator.jsm. 
Looking at the history there:
https://hg.mozilla.org/comm-central/log/tip/mail/base/modules/mailMigrator.js
https://hg.mozilla.org/comm-central/log/tip/mail/base/modules/MailMigrator.jsm
people *will* lose their custom font sizes if they downgrade.

So whether you land the patch that at least changes the Firefox strings 
to Thunderbird, and please soon now, since the l10n train has left the 
station a long long time ago, or remove the downgrade blocking, in the 
end, it makes no difference. Coming to think of it, the best option 
would be to change buttons of the warning to: "Exit", "New Profile" and 
"Just do it" so people don't have to scramble to add -allow-downgrade to 
the invocation of the executable.

Jörg.



More information about the tb-planning mailing list