Downgrade from Firefox 63 clears local storage of all add-ons

Add-ons Development
#1

Hello,

I’ve just read very troubling article about upcoming “upgrade”:

After reading this I was shocked that the situation from a year ago with Firefox 57 is gonna repeat. I decided to try it for myself and indeed, the local storage (not IndexedDB) will be wiped out with ALL USER DATA!!!

Now as an add-on developer I’m pretty sure I’m gonna receive SO MANY e-mails and I will get bad reviews saying how my add-on suddenly lost all data. And I know it because I’m still receiving e-mails from users that downgraded from 57 and it’s been almost a year now!
I realize that situation with 57 was different and there were more users downgrading than ever before. However there are still many users with Beta / Nightly version that are used with the same profile - because they either don’t know about Profile Manger or they don’t want to use more profiles just to test new version of Firefox.

Can somebody explain me how such a terrible idea - not implementing backwards compatibility - came to the release AGAIN? Why not invest few hours of development to provide backwards compatibility during profile downgrade???

#2

Backward compatibility during profile downgrade is quite hard to do, since it’d require updating the old version to be able to read the new format. The new version doesn’t write the old format anymore for performance reasons, so it can’t just keep up two copies of the same data.

#3

It’s not about old version understand the new format, it’s about creating a downgrade script that will convert new format to the old. It may not be simple but it’s not impossible and it would save so much time for so many developers and users. Not to mention the lost data!!!

#4

How would it know to run the downgrade script?

You can restore the pre-upgrade state of the storage, as outlined in the article you linked.

#5

How about create a folder called 63 during upgrade to 63 and when you run Firefox 60 it would just execute all downgrade scripts from 63, 62, 61 in this order? Or use any other of the million mechanisms available because this is not a new issue, this is something developers face all the time (like writing a downgrade scripts when upgrading schema in SQL database). The lack of such mechanism is just lazy programming.

You mean the 9 steps tutorial? How many users will understand that? And be willing to do that? And how many will even contact me?
I’ve already received e-mail where user write that he already removed my add-on because it lost all data and that I’m a crappy developer.

#6

Hi @juraj.masiar! Just to clarify: the users at risk of data regression during the migration are the folks who regularly switch between Nightly, Beta, and release using the same profile. This should be a relatively small group of advanced users.

The new backend should stabilize by the time Firefox 63 goes into Beta. At that point, users should be able to switch channels without fear of data loss.

However, if you do come across any issues, please do file a new issue on Bugzilla and add it as a blocker of bug 1474562 so that we can promptly investigate it.

1 Like
#7

I’m still skeptical about affected users count.
For the next year, this will affect all those that will decide to use ESR 60 version to keep things more compatible. How many will that be?

And what’s bothering me most, is that it will be the add-on developers doing support for end users for something they cannot affect - something that could and should be avoided by maybe few man-days of a singe person in Firefox team.

#8

The article implies that the storage.js files are renamed to storage.js.migrated and that users who roll back to pre-63 might be able to just rename those files back to storage.js. That’s a lot to ask when the folder names are indecipherable, but it’s do-able.

Another recovery option would be to create an import feature in an extension which can ingest its own storage.js(.migrated) file.