User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

closed and opened firefox after downloading upgrade to version 73

Actual results:

all saved passwords had been deleted. I had not set up a master password, nor saved them under a firefox sync account

Expected results:

it should not have deleted saved passwords.

From the symptoms it's hard to know what the bug actually is, could be a bunch of things. Some might be recoverable (new profile created?). Your best bet for help is to try the folks at https://support.mozilla.org/

Can you look in your profile folder for file names starting with logins. and check the contents of logins.json?

I agree with Dan that Support can help with debugging this.

Greetings I have the same problem. After the automatic update of FF from version 72.2 to FF 73, all saved passwords and credentials were lost, nor did uploading the appropriate files from the backup. Also, no new login could be saved. To be sure, the update did not create a new profile. Support tried, but I didn't get the result, I had to upload back version 69 and disable updates.
https://mzl.la/2SI3ybB

(In reply to Jirka from comment #3)

I had to upload back version 69 and disable updates.

Going back to version 69 brought back your saved logins with the same logins.json + key4.db files? Or did you restore those files from backups before the upgrade?

I'm connecting this to bug 1602020 for now since there were some key encryption changes there for 73. jcj, is there any logging that would be useful to see if this is related to NSS changes?

Roland, it seems like we have two reports here, have you had more than the usual number of users reporting lost passwords with Fx73?

In NSS 3.49.x (Firefox 73) we moved to using AES for passwords; earlier versions of NSS used 3DES. Old password databases should still open fine; there are tests of that.

Bug 1585189's author was Bob; I'll hand this ni? to him and Daiki to see if they have immediate ideas.

When I uploaded back version 69 I used the mentioned files in the backup, but I tried to use those from the updated version and are identical, only version 73 was not able to read.
Sorry about my artificial / translated English.

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #5)

Roland, it seems like we have two reports here, have you had more than the usual number of users reporting lost passwords with Fx73?

hi :mattn I don't see a more than usual number of users reporting passwords with Fx73. i will keep an eye out.

I've confirmed that in the simple case, creating some passwords in ESR 68.0.5 in a new profile without Master Password, then opening that profile in 73, the passwords are present and OK.

So whatever's happening here is not the trivial case, at least.

Greetings All.
So I downloaded off-line versions 72.2 and 73 for the test.
First I reinstalled my uploaded version of 69 version 72.2 and all the saved passwords and credentials and the original profile, which is, as I may not have mentioned earlier data, remained in the settings.
Next I tried off-line installation again and reinstalled version 72.2 version 73, all bookmarks were preserved, but again all stored login data was lost.
Then I tried to uninstall version 73 and reinstall version 72.2. this was not a problem, but the login data was gone = unreadable even if it is in the profile folder. Uploading to a new profile did not help, the data is not showing.
So I'm back with a completely backed-up version of 69, which I just uploaded - not installed, including the profile.
So much for this problem.

[Tracking Requested - why for this release]: 4 reports of logins not being decrypted in Fx73.

It looks like we have another case in https://support.mozilla.org/en-US/questions/1279915. Since about:protections is reporting the correct total it means that the problem is probably with decryption since about:logins use countAllLogins, not requiring decryption. Can others here having the issue confirm that the about:protections page has a reasonable number for "Passwords stored securely"?

Giovanni or Jirka,

Can you remember approximately how old your profile is, or when you started using the internal password database?

It would be great if a few people seeing this issue attached their about:support raw data to this bug (click "Copy raw data to clipboard") and then

FWIW, I was able to get a reproducer with a profile created in Fx57 (with one test password). We are still investigating, but a failure appears at:

* thread #109, name = 'StreamTrans #19', stop reason = step over
    frame #0: 0x0000000101352d39 libnss3.dylib`PK11SDR_Decrypt(data=0x000070000459df90, result=0x000070000459df78, cx=0x000000013f930f20) at pk11sdr.c:365:12
   362 	    type = CKM_DES3_CBC;
   363 	    key = PK11_FindFixedKey(slot, type, &sdrResult.keyid, cx);
   364 	    if (!key) {
-> 365 	        rv = SECFailure;
   366 	    } else {
   367 	        rv = pk11Decrypt(slot, arena, type, key, params,
   368 	                         &sdrResult.data, result);
Target 0: (firefox) stopped.
(lldb) bt
* thread #109, name = 'StreamTrans #19', stop reason = step over
  * frame #0: 0x0000000101352d39 libnss3.dylib`PK11SDR_Decrypt(data=0x000070000459df90, result=0x000070000459df78, cx=0x000000013f930f20) at pk11sdr.c:365:12
    frame #1: 0x000000010b006591 XUL`SecretDecoderRing::Decrypt(this=0x000000017af2ce20, data=0x000070000459e010, result=0x000070000459e140) at SecretDecoderRing.cpp:164:7
    frame #2: 0x000000010b006de4 XUL`SecretDecoderRing::DecryptString(this=0x000000017af2ce20, encryptedBase64Text=0x0000000143db8498, decryptedText=0x000070000459e140) at SecretDecoderRing.cpp:237:8
    frame #3: 0x000000010b005c5e XUL`BackgroundSdrDecryptStrings(encryptedStrings=0x0000000143ef28f0, aPromise=0x0000000143ef28e8) at SecretDecoderRing.cpp:75:22
    frame #4: 0x000000010b040ce5 XUL`SecretDecoderRing::AsyncDecryptStrings(this=0x0000000143ef28e8)::$_3::operator()() at SecretDecoderRing.cpp:268:9
    frame #5: 0x000000010b040bfe XUL`mozilla::detail::RunnableFunction<SecretDecoderRing::AsyncDecryptStrings(nsTArray<nsTString<char> > const&, JSContext*, mozilla::dom::Promise**)::$_3>::Run(this=0x0000000143ef28c0) at nsThreadUtils.h:559:5
    frame #6: 0x00000001018da0d7 XUL`nsThreadPool::Run(this=0x00000001322808d0) at nsThreadPool.cpp:299:14
    frame #7: 0x00000001018cfc50 XUL`nsThread::ProcessNextEvent(this=0x0000000132294780, aMayWait=true, aResult=0x000070000459ebaf) at nsThread.cpp:1220:14
    frame #8: 0x00000001018d7249 XUL`NS_ProcessNextEvent(aThread=0x0000000132294780, aMayWait=true) at nsThreadUtils.cpp:481:10
    frame #9: 0x0000000102824311 XUL`mozilla::ipc::MessagePumpForNonMainThreads::Run(this=0x0000000134196fc0, aDelegate=0x000070000459edd0) at MessagePump.cpp:332:5
    frame #10: 0x00000001026f9108 XUL`MessageLoop::RunInternal(this=0x000070000459edd0) at message_loop.cc:315:10
    frame #11: 0x00000001026f9065 XUL`MessageLoop::RunHandler(this=0x000070000459edd0) at message_loop.cc:308:3
    frame #12: 0x00000001026f8fe8 XUL`MessageLoop::Run(this=0x000070000459edd0) at message_loop.cc:290:3
    frame #13: 0x00000001018cb4d8 XUL`nsThread::ThreadFunc(aArg=0x00007ffeefbfb658) at nsThread.cpp:464:10
    frame #14: 0x00000001012b5f24 libnss3.dylib`_pt_root(arg=0x0000000143a0aec0) at ptthread.c:201:5
    frame #15: 0x00007fff6b9b6d36 libsystem_pthread.dylib`_pthread_start + 125
    frame #16: 0x00007fff6b9b358f libsystem_pthread.dylib`thread_start + 15

JavaScript error: resource://gre/modules/crypto-SDR.js, line 200: NS_ERROR_FAILURE: Couldn't decrypt string

Could one of the reporters please open Tools > Web Developer > Browser Console, and check if that last message from crypto-SDR.js appears?

Ignore that; we can't re-import in any efficient manner.

Hello.
So my profile is definitely old, I've been copying since FF prehistoric times.
I don't know the login and password, but it will be older than FF 30 until I backed it up using MozBackup or saving the profile or the entire Mozilla folder from the AppData \ Roaming folder. There was a period when I dismissed FF and I used PaleMoon exclusively for the changes that came after version 30.
But again he started having trouble with a lot of web sites, so I had to go back to FF, which was long before version 69.
I'm pretty conservative and I really hate changing something that works OK and I don't understand adapting to the mainstream that just flies somewhere ...
So much information about the query.

Thanks, Jirka. That helps! We're working on it. Clearing Giovanni's ni? also, since we now have a reproducer thanks to kjacobs.

So now I didn't quite understand.
Do you want to clarify or add something else?

Hmm are we having problems reading on old dbm database in FF 73? Looking at kjacob's traceback, it's clear we aren't finding the sdr key (which is stored in the database) rather than having problems with the actual encrypted passwords (which are stored elsewhere in the profile). This is consistent with failure to decrypt the key in the database. Even if you have no master password, the sdr key is still stored in the database encrypted.

If firefox did not try to prompt for a password before trying to read the encrypted password, then we were able to decrypt the password entry correctly. That means the issue is decrypting the SDR key. Once complication with the old dbm code is we have to decrypt the entry then encrypt the actual key data and pass it back up to the generic database code for decryption. This is because we store data encrypted in a different format in the dbm, so it can't use the generic code to decrypt. The upshot is the failure could be in any one of the three (initial decrypt, internal encrypt, internal decrypt). The new AES code add integrity as well, but the integrity checks should be skipped for dbm since it can't store the appropriate meta data. Failure in that code could cause issues as well.

Anyway it would be good to check to see if we are running into a dbm failure.

Yeah, that's actually where we are now. Firefox 73 removed DBM entirely, setting disable_dbm to true on builds ( Bug 1594931 ) since we changed over to SQLite in Firefox 58, but this makes it appear that there were cases where we were still falling back to DBM even post-migration, or perhaps cases where the migration code was unsuccessful in some way where DBM was serving as fallback.

Perhaps we need to re-trigger the migration in a Firefox between 58 and 72 (inclusive) in some fashion. Just not sure yet how to do that safely (without deleting the key4/cert9 files from the profile).

I think it's a good idea to force out all the old dbm databases, but the NSS code should handle the dbm case still (well unless libnssdbm.so has been removed -- then all bets are off).

Totally removed in Firefox 73, yes.

I am wondering if these profiles are being taken directly from pre-58 to 73, as via a backup restore? Perhaps all that needs to happen is to run Firefox 68 and let them migrate, then move to 73. (This was raised by :emk in Bug 1607798 last month)

With our reproducer test case, we've confirmed that going from Firefox 57 to ESR 68 to 73 results in passwords working. Specifically:

Open 57.
Create a new profile.
Save a password.
Close 57.

Open ESR 68.
Load the same profile.
Confirm passwords are visible in about:preferences
Close ESR 68.

Open Release 73.
Load the same profile.
Confirm passwords are visible in about:logins
Close Release 73.

If you're affected:

Confirm you still have key3.db and cert8.db in your affected profile dir.
Make a good backup of your affected profile dir.
Try removing key4.db and cert9.db from your affected profile dir.
Load the profile in ESR 68. Use --allow-downgrade if necessary.
See if passwords are accessible.
Then try loading that same profile in Firefox 73.
If that works, for safety, I recommend removing the now-migrated key3.db and cert8.db after confirming 73 can show the passwords.

Still working on a better solution.

It is great that there is an effort to solve the problem, but hopefully I will not try this somewhat breakneck way. So far it is easier to stay on FF 69.0.1 or try FF 72.2. However, if I misunderstand what you write, I apologize.

(Clearing Daiki's ni.)

I don't have any new ideas on this. Moving a profile between 57, 68, and 73 leads to lots of odd situations because Firefox/NSS only tries to upgrade the databases once. If a profile upgraded, but then went back to a previous version and added more passwords, or got to the same position through a profile backup/restore, then we get into this sort of in-between state.

There's not much for code-fixes that we can realistically do here. DBM was removed for serious security reasons. These users' databases weren't migrated automatically for some reason, and need to have the new key4.db and cert9.db files in the profile deleted to re-do that migration. If we added DBM back, we would still have to either have users take manual action, or dramatically increase the complexity of the migration code (to open both databases every time and somehow determine what needs to merge and where).

If passwords aren't showing up in Firefox 73 but were in prior versions, the solution will have to be to force a migration using Firefox 72 or earlier (like ESR 68). Critically, if there are both key3.db and cert8.db alongside key4.db and cert9.db files in the profile, the newer key4.db and cert9.db files will need to be backed up and then deleted, and then the profile opened with a version of Firefox between Firefox 58 and Firefox 72 (such as ESR 68). Afterward, upon verifying everything is OK, key3.db and cert8.db can be deleted.

Roland, perhaps the real solution here is to write up a SUMO article about fixing loss-of-passwords in Firefox 73 and later, and walk through these steps. What do you think?

(In reply to J.C. Jones [:jcj] (he/him) from comment #25)

(Clearing Daiki's ni.)

I don't have any new ideas on this. Moving a profile between 57, 68, and 73 leads to lots of odd situations because Firefox/NSS only tries to upgrade the databases once. If a profile upgraded, but then went back to a previous version and added more passwords, or got to the same position through a profile backup/restore, then we get into this sort of in-between state.

There's not much for code-fixes that we can realistically do here. DBM was removed for serious security reasons. These users' databases weren't migrated automatically for some reason, and need to have the new key4.db and cert9.db files in the profile deleted to re-do that migration. If we added DBM back, we would still have to either have users take manual action, or dramatically increase the complexity of the migration code (to open both databases every time and somehow determine what needs to merge and where).

If passwords aren't showing up in Firefox 73 but were in prior versions, the solution will have to be to force a migration using Firefox 72 or earlier (like ESR 68). Critically, if there are both key3.db and cert8.db alongside key4.db and cert9.db files in the profile, the newer key4.db and cert9.db files will need to be backed up and then deleted, and then the profile opened with a version of Firefox between Firefox 58 and Firefox 72 (such as ESR 68). Afterward, upon verifying everything is OK, key3.db and cert8.db can be deleted.

Roland, perhaps the real solution here is to write up a SUMO article about fixing loss-of-passwords in Firefox 73 and later, and walk through these steps. What do you think?

Thanks for the update. I conclude the following please let me know what I'm missing :-)

1. we removed support for DBM in FF73
2. in some Firefox upgrade scenarios from pre FF73 which has DBM to FF73 there is a bug
3. but there is a manual workaround (force migration, then backup and delete certain files)
4. it's easier to document this manual workaround then to fix the software
5. we've only had 3 cases of this bug in SUMO forums we don't think it's high volume but it's a bug
6. assuming i'm not missing anything i'm fine with a SUMO KB article for this
7. needinfoing our SUMO KB content editor, joni, to get her thoughts

Thank you all for trying to solve the problem.
I do not know what people who program something around FF or trying to remedy, but I still allow one little comment. Meanwhile, it's about eliminating the effect, but the cause is left as it is, because we don't know it.
Are you wrong?
I don't want to work with a profile anymore, record different versions of FF and hope it's OK. As a really long-time FF user (or Thunderbird) we are not satisfied with where FF is going. logging in, sharing, kernel changes, adapting to so-called trends, and more.
That's what Mozila and FireFox really need ...

Thanks again for the effort, but I'll wait as it turns out with the next version and if the FF will not be able to work with what worked years before and without what is called the current trend, the FF for me probably past.
All the best .
May the Force guide you.

Jirka / George

Another user with the problem has solved this, as shown below, which seems to confirm that the appropriate files will be preserved, but FF 73 simply does not load them, even if version 72 does.
vejv 1 solution of 3 answers
Added
Today at 13:01
So just write. I backed up the entire profile folder, uninstalled firefox 73, downloaded the FF72.0.2 installer, disconnected from the Internet, installed, disabled updates, copied the profile folder and voala back, got the FF back and forth, including all passwords,

https://mzl.la/2uW6BVW

(In reply to Kevin Jacobs [:kjacobs] from comment #14)

FWIW, I was able to get a reproducer with a profile created in Fx57 (with one test password). We are still investigating, but a failure appears at:

* thread #109, name = 'StreamTrans #19', stop reason = step over
    frame #0: 0x0000000101352d39 libnss3.dylib`PK11SDR_Decrypt(data=0x000070000459df90, result=0x000070000459df78, cx=0x000000013f930f20) at pk11sdr.c:365:12
   362 	    type = CKM_DES3_CBC;
   363 	    key = PK11_FindFixedKey(slot, type, &sdrResult.keyid, cx);
   364 	    if (!key) {
-> 365 	        rv = SECFailure;
   366 	    } else {
   367 	        rv = pk11Decrypt(slot, arena, type, key, params,
   368 	                         &sdrResult.data, result);
Target 0: (firefox) stopped.
(lldb) bt
* thread #109, name = 'StreamTrans #19', stop reason = step over
  * frame #0: 0x0000000101352d39 libnss3.dylib`PK11SDR_Decrypt(data=0x000070000459df90, result=0x000070000459df78, cx=0x000000013f930f20) at pk11sdr.c:365:12
    frame #1: 0x000000010b006591 XUL`SecretDecoderRing::Decrypt(this=0x000000017af2ce20, data=0x000070000459e010, result=0x000070000459e140) at SecretDecoderRing.cpp:164:7
    frame #2: 0x000000010b006de4 XUL`SecretDecoderRing::DecryptString(this=0x000000017af2ce20, encryptedBase64Text=0x0000000143db8498, decryptedText=0x000070000459e140) at SecretDecoderRing.cpp:237:8
    frame #3: 0x000000010b005c5e XUL`BackgroundSdrDecryptStrings(encryptedStrings=0x0000000143ef28f0, aPromise=0x0000000143ef28e8) at SecretDecoderRing.cpp:75:22
    frame #4: 0x000000010b040ce5 XUL`SecretDecoderRing::AsyncDecryptStrings(this=0x0000000143ef28e8)::$_3::operator()() at SecretDecoderRing.cpp:268:9
    frame #5: 0x000000010b040bfe XUL`mozilla::detail::RunnableFunction<SecretDecoderRing::AsyncDecryptStrings(nsTArray<nsTString<char> > const&, JSContext*, mozilla::dom::Promise**)::$_3>::Run(this=0x0000000143ef28c0) at nsThreadUtils.h:559:5
    frame #6: 0x00000001018da0d7 XUL`nsThreadPool::Run(this=0x00000001322808d0) at nsThreadPool.cpp:299:14
    frame #7: 0x00000001018cfc50 XUL`nsThread::ProcessNextEvent(this=0x0000000132294780, aMayWait=true, aResult=0x000070000459ebaf) at nsThread.cpp:1220:14
    frame #8: 0x00000001018d7249 XUL`NS_ProcessNextEvent(aThread=0x0000000132294780, aMayWait=true) at nsThreadUtils.cpp:481:10
    frame #9: 0x0000000102824311 XUL`mozilla::ipc::MessagePumpForNonMainThreads::Run(this=0x0000000134196fc0, aDelegate=0x000070000459edd0) at MessagePump.cpp:332:5
    frame #10: 0x00000001026f9108 XUL`MessageLoop::RunInternal(this=0x000070000459edd0) at message_loop.cc:315:10
    frame #11: 0x00000001026f9065 XUL`MessageLoop::RunHandler(this=0x000070000459edd0) at message_loop.cc:308:3
    frame #12: 0x00000001026f8fe8 XUL`MessageLoop::Run(this=0x000070000459edd0) at message_loop.cc:290:3
    frame #13: 0x00000001018cb4d8 XUL`nsThread::ThreadFunc(aArg=0x00007ffeefbfb658) at nsThread.cpp:464:10
    frame #14: 0x00000001012b5f24 libnss3.dylib`_pt_root(arg=0x0000000143a0aec0) at ptthread.c:201:5
    frame #15: 0x00007fff6b9b6d36 libsystem_pthread.dylib`_pthread_start + 125
    frame #16: 0x00007fff6b9b358f libsystem_pthread.dylib`thread_start + 15

JavaScript error: resource://gre/modules/crypto-SDR.js, line 200: NS_ERROR_FAILURE: Couldn't decrypt string

Could one of the reporters please open Tools > Web Developer > Browser Console, and check if that last message from crypto-SDR.js appears?

YES
https://drive.google.com/file/d/1-rZmdJvjcf3mXLjTfO__q9pWbMN57w8W/view?usp=sharing

Good evening.
Adding info about the experiment: I reinstalled my version 69 with version 72.0. After restart, there was a message about the necessity to create a new profile, I did this and then I chose and set my old profile as the main one in about: profiles. I restarted, disabled updates, and reviewed the saved passwords and credentials. Everything was preserved even in the strange and dysfunctional new system.
Subsequently, I tried to reinstall this version with a version of 74.0b9 (64 bits), because I did not try it and I hoped for a miracle.
Unfortunately, the miracle did not happen.
After the reboot, the passwords and credentials were gone, and no more new ones were written, so I'm back at version 69.
So long live the old classics ...
Of course, re-installing to 72.0 did not help.
So still bad.

Hello,
just a minor addition.
I don't know how and why, but the FF has updated myself from version 69 to 72.0.2. The problematic data has been preserved, so I downloaded the offline update to version 74 which it offered in the About Firefox tab. Interestingly, the pushy automatic update offer that can't be turned off still offered me version 73.0.1. After the reinstallation of the 74 versions, however, nothing has changed and everything is the old, saved login data and passwords are gone. And another interesting thing is that I cannot create a master password in the password manager, it just tells me that the master password cannot be changed, okay, but there is no old one ...
It seems that if I want to stay at FF I will have to save all passwords gradually because passwords can be imported but not exported anymore.
Gold good old version ...

JC, is there a way to figure out why Jirka's profile is not being migrated properly?

And especially why it goes to 72.0.2 and then not :-(

No, not without both the profile and the password.

I do believe the steps in the second half of https://bugzilla.mozilla.org/show_bug.cgi?id=1615382#c23 should fix it, however, Jirka. Closing Firefox, removing the obviously-empty "new" files, and restarting the profile in ESR 68 should re-migrate everything and solve the issue going forward.

Hello,
so I admit that I didn't understand that much.
OK download offline version of FF 68 I will upload my profile into it and I will gradually update.
Then I'll let you know.

Proposed Support article for users facing this issue: https://docs.google.com/document/d/1-9tQk2kB-jU7J01ZeglmrTrNItR8Hzk5WimoxZbf4rg/edit?usp=sharing

Please let me know your comments before this is published.

account with authorization, need to log in, this is nothing for me :-)

(In reply to Jirka from comment #37)

account with authorization, need to log in, this is nothing for me :-)

Hi Jirka,
This document is limited to Mozillians only, sorry! I will share the link to it when it is live on the support site.

I tried this procedure:

1. / I reinstalled FF 72.0.2 with FF 57 version
   Passwords and credentials present I managed to enter the master password.
2. / I reinstalled FF 57 versions of FF 68
   Passwords and credentials are present, old password required master password and offered update to ver 72.0.2, also add-ons that were not supported by FF 57 were loaded
3. / I reinstalled FF 68 versions of FF 72.0.2
   Passwords and credentials are present.
4. / I reinstalled FF 72.0.2 directly to FF 74 (I decided to skip version 73)
   Passwords and credentials gone…
5. / reinstallation of older versions of FF 68 did not succeed, the profile does not load and cannot be opened even with about: profiles in another panel = always offers only a new profile because it does not allow to load the older profile…
   These * .db files are all present.
   Removing goes nowhere
6. / uninstall, restart PC i, install FF 72.0.2 with pre-loaded profile.
   Passwords and credentials are present, master password cannot be entered, writes that it cannot be changed even if there is none.
7. / remove cert9.db and key4.db = passwords present and master password can be set
   But passwords appear with a large delay of a few seconds.
8. / Reinstall FF 72.0.2 with FF 73.0 versions
   Passwords and credentials present, but appear with a large delay of a few seconds.
   Master password present.
9. / Reinstall FF 73.0 with FF 74
   Passwords and credentials present, but appear with a large delay of a few seconds.
   Master password present.
   10./ see what happens next, I am quite puzzled by the delay before the passwords are displayed, but I am also with passwords and credentials for FF 74.0…

So far thank you and any difficulties or changes I will make here on the forum.

Great, and thanks for the details there Jirka.

Try resetting your master password - even if you set it to the same password over. Because of https://bugzilla.mozilla.org/show_bug.cgi?id=1606992#c70 , resetting your password on Firefox 73+ should speed things up.

Also, I'm sorry about the problem with Step 5 about the older profile. There's a command line flag, --allow-downgrade, but what you did obviously works too!

OK and thank you for your support and instructions, but I did not do it exactly as described, but mainly that it goes - Hooray!
Otherwise, the delay before the passwords are displayed and the login data is about 3 to 5 seconds.
So far I leave it as it is, somehow I do not want to reinstall it, delete and record again and again.

Make the best of it.

(In reply to Angela Lazar from comment #36)

Proposed Support article for users facing this issue: https://docs.google.com/document/d/1-9tQk2kB-jU7J01ZeglmrTrNItR8Hzk5WimoxZbf4rg/edit?usp=sharing

Please let me know your comments before this is published.

Done

New support article created for this issue:

https://support.mozilla.org/en-US/kb/lockwise-losing-login-information-when-upgrading-f

Since it seems like we aren't going to make any code fixes for this we can probably resolve the bug as WONTFIX.

Re-open if you disagree.