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

Steps to reproduce:

I have 750 stored logins in Firefox Lockwise, and I use Firefox Sync to sync the logins.

I opened the Firefox Lockwise dialog (via "about:logins" or from the settings).

Actual results:

The dialog opens immediately, but it takes around 7 seconds until the logins are shown. It also takes 7 seconds before searching works.

Expected results:

A delay of 7 seconds is a very long time. I would expect the logins to be shown more or less immediately and also to be searchable immediately.

I assume the delay grows linearly with the number of stored logins. 750 stored logins doesn't sound like a whole lot.

Maybe paging should be used instead of showing all logins in one large scroll area?

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Thank you for filing this bug. This might be caused by slower decryption on Windows, and the fact that we decrypt every login on page load currently.

Are you using portable Firefox or storing your Firefox profile on an external device (e.g. flash drive, network folder, ...)?

No, I'm using a normal (non-portable) installation of Firefox 79.0 on Windows 10 Enterprise (Version 1803), on a Dell Precision 7520 laptop (2.9 GHz i7 Processor) with a 512 GB SSD and 32 GB memory. The profile is stored on the SSD, no network folders or external devices are used. With an idle CPU it takes 5 seconds to show the logins when about:logins is used.

I've noticed that the same logins (they are synced) open much faster on my 3.6 GHz i9 desktop machine. There it takes slightly less than 1 second. Same Firefox version, but Windows 10 Home (Version 2004).

Is it possible to run some profiling within Firefox, e.g. how long the decryption takes vs. other functionality when the logins are opened?

Thanks for the information.

Do you use Primary Password (formerly Master Password)? I ask, because that can further slow down decryption of logins.

Is it possible to run some profiling within Firefox, e.g. how long the decryption takes vs. other functionality when the logins are opened?

Yes it is. Would you be comfortable capturing a profile of the about:logins page load in the slow case? There are some instructions for how to report a performance problem on MDN.

No, I do not use a master password.

What I did now:

• Start Firefox
• Start capturing
• Open about:logins
• Stop capturing

The result is here: https://share.firefox.dev/31lb5mp

As you can see, it took 5 seconds to show the logins.

Thanks Thomas. Apologies, but it looks like the thread that decryption runs in (StreamTrans) is not enabled by default for any of the profiler presets. Would you mind recording one more time with that thread enabled?

1. In the presets dropdown for the Profiler popup, select Custom
2. Click Edit Settings
3. Under Profiler Settings, select the Firefox Front-End preset
4. Under Threads, enable StreamTrans

It is rather alarming that it looks like decryptMany is taking around 4000ms for 750 logins, which would mean an average of around 5ms to decrypt each login... which is orders of magnitude longer than I would expect. Thomas, is there any chance that one of these logins is very long? Were these logins imported from another profile? A quick way of getting an idea of this would be to export the logins to a file from the ... menu in about:logins, and see how big the file is. For reference, I have 210 logins in my profile, and the file is 40KB.

Same issue here.

https://profiler.firefox.com/public/mah2tgytn94bkmkaf09ea81mnv9ktnm2bsv8ez0/calltree/?globalTrackOrder=0-1&localTrackOrderByPid=24804-2-0-1~16828-0~&thread=0&v=5

The profile for the laptop above is from a laptop with a Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz, 2808 Mhz, 4 Core(s), 8 Logical Processor(s) [Intel64 Family 6 Model 158 Stepping 9]

Here is a profile capture of about:logins from a laptop with a Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz, 2300 Mhz, 2 Core(s), 4 Logical Processor(s) [Intel64 Family 6 Model 42 Stepping 7] and the wait is painful. The user will start to believe that al their stored credentials have been lost. A progress indicator is very much needed.

https://profiler.firefox.com/public/rrv9j00t6epq361cpmjvbxwx2n1nanq0hcqb4qg/calltree/?globalTrackOrder=0-1-2&localTrackOrderByPid=3732-4-5-0-1-2-3~14532-1-0~18952-0-1~&thread=7&v=5

Profiling of the of the Intel(R) Core(TM) i3-2350M went wrong. Re-profiled and here is the link:

https://profiler.firefox.com/public/p052ayyrqd7acnreh35wdtq8r2nqx79ckey8bjr/calltree/?globalTrackOrder=0-1&localTrackOrderByPid=13716-2-0-1~12192-0~&profileName=Firefox%2085%20%E2%80%93%20Windows%2010%20-%20Intel%28R%29%20Core%28TM%29%20i3-2350M%20CPU%20%40%202.30GHz%2C%202300%20Mhz%2C%202%20Core%28s%29%2C%204%20Logical%20Processor%28s%29&thread=0&v=5

Looking at the last 2 profiles, the time doesn't seem spent on CPU, but on disk I/O, most of the time in the StreamTrans thread is in NtQueryFullAttributesFile called by sqlite.

Created an export of saved credentials. The size of the exported file is 222 KB (228,134 bytes). 1290 web credentials stored.

Could a progress indicator/bar, in the interim, be shown as the credentials are being loaded and decrypted to show that Firefox is actually doing something? Ref. enhancement request 1687563

I created an export. It contains 758 entries and is 135 KB in size.

I captured another run of about:logins using Firefox 84.0.2 on my Dell laptop (see above for specs). It is available here: https://share.firefox.dev/3ixQS3B
As you can see, almost 6.5 seconds are spent by StreamTrans for loading 756 entries, which is around 8.5 ms per entry.
Any idea why this is so slow?

I made another run of about:logins using Firefox 84.0.2 on my desktop machine (see above for specs). It is available here: https://share.firefox.dev/3p6U48E
Here StreamTrans is only busy for 566 ms for loading 756 entries, which is around 0.75 ms per entry.
Why such a big difference?

Fun fact: When using my laptop and running a Linux VM (CentOS 7), Firefox 84.0.2 takes around 1 second to open the same amount of logins.
So on the same machine on Windows I get a poor performance for about:logins, while running in a Linux VM on that machine gives a much better performance. Really weird.

This profile https://share.firefox.dev/392VVWs from comment 11 shows more than 90s spent before displaying about:logins. Most of the time (84s in the StreamTrans thread, and 3.8s on the main thread) is spent in PK11SDR_Decrypt doing disk I/O with SQLite.

I captured another profile on a test machine with an almost empty user profile (I saved 5 passwords so that about:logins wouldn't be completely empty) with the fileio feature of the profiler to see which files are accessed: https://share.firefox.dev/391ypct

It's the key4.db-wal and key4.db-journal files accessed many many times. How could we avoid touching the disk all the time when accessing this database?

This is probably a consequence of NSS keeping persistent keys in a sqlite database in shared mode. You could probably work around this by moving away from the PK11SDR API (because that's what stores the key in the db). It would be great if we could finally use nsIOSKeyStore: https://searchfox.org/mozilla-central/source/security/manager/ssl/nsIOSKeyStore.idl (although there are some open UX questions with that such as what happens when a Firefox profile moves between OSes).

I've decided to profile about:logins on Linux under WSL2 and Windows 10. There is now a fly in the ointment

Between yesterday and today the system has not been rebooted. Just hibernated.

First I profile Firefox on Linux and right after that profile Windows.

Same hardware except first is Firefox 84.0.2 on Ubuntu 20.04 on Microsoft's WSL2 kernel.
Linux Norbert-wsl 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
https://profiler.firefox.com/public/k7xzh0h049jv9wyveqr0xfxgthzexgs51a7gq1r/calltree/?globalTrackOrder=0-1&localTrackOrderByPid=1780-0-1-2-3~1975-0~&profileName=Firefox%2084%20%E2%80%93%20Linux%20-%20Microsoft%20WSL2%20using%20latest%20kernel&thread=3&v=5

Now Windows 10. Same profiler data gethering settings as the above.
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19042
https://profiler.firefox.com/public/8p6bwgn88w0kstscpdv70xbm8dy6nknxwf7xtd0/calltree/?globalTrackOrder=0-1-2&localTrackOrderByPid=12260-2-0-1-3~10572-0-1-2~33700-0-1~&profileName=Firefox%2085%20%E2%80%93%20Windows%2010%20Pro%20-%2010.0.19042%20Build%2019042&thread=5&v=5

This time all the login credentials appeared on Windows Firefox within about 8 seconds and not about 67 seconds. Nothing on my computer got updated between firefox profile data gathering between comment 10 and now.

Some more information. I'm not sure if what I did is related in anyway to this issue.

I replaced Oracle Java Runtime Environment with OpenJDK 15 and OpenJ9 JVM.
https://profiler.firefox.com/public/dhx163afc8mbj82sqb97vtz5tzkb737est5fzn0/calltree/?globalTrackOrder=0-1-2&localTrackOrderByPid=4548-2-0-1-3~24312-0-1-2~21036-0-1~&profileName=Firefox%2085%20%E2%80%93%20Windows%2010%20-%20Oracle%20Java%20replaced%20with%20Open%20Java%2015&thread=5&v=5

JAVA_HOME variable has been set:
JAVA_HOME=C:\Program Files\AdoptOpenJDK\jdk-15.0.1.9-openj9\

Does the installed Java Environment affect how Firefox behaves?

(In reply to Myron from comment #24)

Does the installed Java Environment affect how Firefox behaves?

It shouldn't affect Firefox, no. What will make a difference is how busy the disk is outside of Firefox. In the Task Manager, the disk column is sometimes close to 100% when some background tasks are running (eg. preparing the installation of a Windows update). We identified with the profiles here that the slow part is due to doing a lot of disk I/O, so if something else on the system is using the disk at the same time, this will be dramatically slower.

Just when you think that you've nailed down the problem .... :-(

Data is on a conventional Seagate HDD and that drive is reasonably quiet. The system drive is a Samsung PCIe NVMe M.2 drive.

I wonder.... What if I find the relevant FF's database file where passwords are recorded, move that one file to the SSD and create a Symlink as the profile is on the HDD. Reason for that is to protect the SSD from the many writes FF makes while it's in operation.

Now..... Which file in the profile contains all the web credentials.....

.... well, that was a pointless post from me. key4.db [288 KB (294,912 bytes)] and logins.json [681 KB (697,907 bytes)] are located on the Samsung SSD drive and that beast is quick enough for my needs.

Sequential (MB/s):
Read - 2906
Write - 1865

Ransom (IOPS):
Read - 157470
Write - 77636

In comparison to the Seagate HDD that's the second drive used for data and other stuff that does not require the use of a fast storage media.

Sequential (MB/s):
Read - 64
Write - 69

Ransom (IOPS):
Read - 146
Write - 732

Hi dana,
I have some questions regarding switching from PK11SDR API to OSKeyStore API.
It will be great you can help answer these, thanks!

• Do we plan to switch all usages of PK11SDR API to OSKeyStore API? If yes, what is the timeline?
• It seems that changing to OSKeyStore API has the performance benefit, are there any other benefits?
• Could you help roughly estimate the effort of switching to the OSKeyStore API (exclude migration)?

One comment regarding the profiles I posted (see comments 18, 19 and 20): On my laptop on Windows I have McAfee antivirus running, which may play a big role in the slow display of the logins (it could be that each sqllite file access is heavily impacted because McAfee intercepts each access and virus-scans the file). This would also explain why on a Linux virtual machine (no McAfee) running on the same hardware the performance is much better; Windows on my desktop machine also has no McAfee installed and performs well. Unfortunately, I cannot turn off McAfee on my laptop since the domain policy forbids that.

Can someone else with a virus scanner on Windows compare the performance with and without the virus scanner enabled?

(In reply to Dimi Lee [:dimi][:dlee] from comment #28)

• Do we plan to switch all usages of PK11SDR API to OSKeyStore API? If yes, what is the timeline?

I am not aware of any plan to use the new API. If frontend wants to use it, frontend needs to make it happen.

• It seems that changing to OSKeyStore API has the performance benefit, are there any other benefits?

There's also a security benefit - without this API, the key that encrypts these secrets is stored in the profile (in key4.db). For 99% of users, this key is stored essentially unencrypted.

• Could you help roughly estimate the effort of switching to the OSKeyStore API (exclude migration)?

Using the new API should be almost a drop-in replacement. Testing it might be hard, since it involves OS interaction. The harder part is dealing with the edge cases of "the user stored some secrets with a key that is no longer available (e.g. profile restored from a backup, profile moved to a new OS account, etc.)" I don't know how much work that would be - most of those are UX questions.

Adding a see also, since this performance issue could potentially get resolved by Bug 1701660.

Could someone who is also experiencing slow loading times and uses McAfee on Windows check if the performance is better if McAfee is turned off? I suspect the virus scanner may slow this down, but I can't turn it off on my machine.

Another solution that improves security and performance but doesn't have the dataloss issues of OSKeyStore is to not decrypt all the passwords when about:logins is opened (see also: bug 952869). That would cut the decryption time in half since only the usernames would need to be decrypted. The password can be decrypted on demand when entering edit/reveal mode or when Copy is clicked. With this approach we also don't have all the passwords needlessly hanging around in memory. If we still want to show the correct length of the password (that's debatable, at one time UX said to use a consistent fake length) then we could prefetch it lazily when the login is visible in the sidebar or when the login is clicked.

(In reply to Thomas Schuerger from comment #32)

Could someone who is also experiencing slow loading times and uses McAfee on Windows check if the performance is better if McAfee is turned off? I suspect the virus scanner may slow this down, but I can't turn it off on my machine.

@Thomas: I am not using McAfee at all, only Windows Defender. I am a long-term user of Firefox, and did not have this "slow loading of passwords" issue till maybe a month ago. I cannot make out what has changed (in my system, in my FF profile, or FF version). But the problem is acute. I am using Windows 10 Pro on a Lenovo X1 Carbon 6th Gen i7 laptop with an SSD disk. The problem is ACUTE: way more than 7 sec delay. More like 1 minute (erratic).

Curiously, the problem does not occur on my 'slower' Dell i5 which is running Windows 10 Home, WITH McAfee.

As a novice in this, my guess is something changed in a recent Window 10 update that triggered this problem.
Any suggestions welcome

For me the time until the passwords show up also increased dramatically with loading times up to 1 minute or so. I am using firefox for years now and the problem started about 1 month ago as others mentioned.
More info:
Stored passwords: ~200
Master Password set: yes
OS: Linux Mint Cinnamon

Like this it always takes really long until I can finally use a password.. It needs to be resolved for usability of the password manager for sure.

@luca.h94, try changing your primary password. You can change it back to what you're currently using, but changing it should fix it if your issue is anything like Bug 1729930.

@Sharad, are you using a primary password? If so, change your primary password. It can be changed to what you were using previously, it just needs to be changed to update the database and resolve the performance issue.

Well, thanks @Tim Giles! That change of Master password certainly worked. The time until passwords show up is now down to about 4 seconds. I can live with that. Don't know why it worked, but it did!

Similar issue resolved by resetting Primary Password.

Worked for me too @Tim Giles. Vielen Dank

Hi, I am face this problem with Firefox 84.0.2, running in a Linux VM (CentOS 7), takes 1 second to open the same number of logins on my laptop.I am also experience the issue when I am loging with my site https://tothefinance.com/ .Plz give me the solution because I am working at my site at daily basis.
But on the same Windows machine, I get a poor performance for about: logins, whereas running in a Linux VM on that machine gives a much better performance. Strange.

(In reply to Jason B. Maldonado from comment #40)

Hi, I am face this problem with Firefox 84.0.2, running in a Linux VM (CentOS 7), takes 1 second to open the same number of logins on my laptop.I am also experience the issue when I am loging with my site https://tothefinance.com/ .Plz give me the solution because I am working at my site at daily basis.
But on the same Windows machine, I get a poor performance for about: logins, whereas running in a Linux VM on that machine gives a much better performance. Strange.

Hi Jason, can you try to reset your Primary Password? Also can you update to recent Firefox, version 84 is rather old now.