Password manager incredibly slow on Windows 7 with USB drive




3 months ago
4 days ago


(Reporter: davofanmail, Unassigned)


65 Branch

Firefox Tracking Flags

(Not tracked)



(2 attachments)



3 months ago

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

Steps to reproduce:

Install Firefox latest release on USB SSD
Put profile on the same drive.
run Firefox on Windows 7 64 bit pro
Go to Options>Security>Saved Logins...push button

Actual results:

My list of saved logins takes as long as 2 minutes to load, during which time the CPU utilization is nearly 0, nearly 0 i/o and network, memory not very busy.
Browser goes into (Not Responding) mode
The pop-up doesn't even start to paint for over a minute
If I access the password manager via the url (chrome://passwordmgr/content/passwordManager.xul), the initial frame doesn't even paint for at least 30 seconds, and it stays blank until all of a sudden the full set shows up.
Occasionally, I'll get a "script not responding" popup, indicating line 236 (?) from the password manager script.

Expected results:

On my Win10 64 bit pro box, the exact same sequence completes fully in less than 2 seconds. The new box isn't that much faster...but the CPU utilization during those 2 seconds is pretty decent. The Win7 box just seems to be waiting for something to occur before it gets to work on the password manager list.
I messed around with Safe mode and using the most bare-bones profile...nothing seems to make much of a difference.
Win7 box has plenty of memory and runs on the same network as the Win10 box.


Comment 1

3 months ago

If I repeat the process of building the logins list, it takes just as long as the first time. I don't know if any of the results are supposed to be cached somewhere, but if so it isn't working on the Win7 box.
Size of logins sqlite is about 725 kB

Component: Untriaged → Password Manager
Product: Firefox → Toolkit

This seems related to bug 1429560. Can you try the NSS_SDB_USE_CACHE potential solution there?

Flags: needinfo?(davofanmail)
See Also: → 1429560

Comment 3

3 months ago

I will try the CACHE environment variable when I get some time on the affected machine.
However, since the Firefox code and all its data are on an SSD connected thru USB 3.0, it's hard to believe that filesystem speed is an issue. But...with the wonders of Windows, who knows. I will experiment.

Updates from my original post:

  • I took the SSD thumbdrive and ran everything successfully on a different Win10 box. I had exactly the same results--nearly instant load of all my logins, even though it's a slower CPU than the Win7 boxes.
  • I then tried the SSD thumbdrive and ran everything successfully on a different Win7 box...but success means "it ran", not "it loaded the password list fast." This other Win7 box also took well over a minute to show the list.
  • Note that all boxes involved in these tests are 64-bit pro versions of windows, have plenty of memory, and run on SSD internal system drives.
Flags: needinfo?(davofanmail)

Comment 4

3 months ago

OK, I tried the environment variable suggestion, it made no difference.
Of course, the original suggestion of that environment variable was in a Linux instance, possibly the name is different in Windows??
Is there something meaningful I can do with Process Explorer or some other tool that would provide you some clues?


Comment 5

3 months ago

Looking at Process Explorer, it seems that there's just a really slow sort going on...but why it's slow is not apparent, as the memory changes very little during the "waiting to paint" cycle, and there's little disk I/O. No page faults to speak of.
Is it possible there's some MSFT or open-source library you're depending on that isn't there by default in Win7?


Comment 6

3 months ago

Validated that this issue has something to do with the way Windows 7 works with "external" drives; perhaps its a caching strategy, or a cohrency-check they do endlessly while FF is trying to sort the list of logins/passwords.
If the Profile is on the C drive, everything is quick.
If the Profile is on the SSD USB 3.0 drive, the password mgr crawls.
What's weird is the kernel CPU usage doesn't go crazy--something in the file system is just waiting around (maybe for some device-driver flag...)
Will experiment with external drive settings to see if I can find a workaround on Win7.
Note that on both the Win7 and Win10 boxes, the external drive has the write-caching disabled (allowing "quick removal"), but the speed difference for password manager is amazing (> an order of magnitude on the same hardware and OS, comparing profile-on-C vs profile-on-external).


Comment 7

3 months ago

Did some more testing with the caching/performance settings on the USB SSD drive. Made no difference.
Is there some library FF is depending on that has changed its algorithms between Win7 and Win10?


Comment 8

3 months ago

FWIW, I don't believe this is a duplicate of bug 1429560.
I am happy to test any code if you end up tackling this one.

Thanks for all the info! Can you use the Firefox profiler to capture the slow operation. Then we can pinpoint which Firefox code is the problem (with a stack):

Flags: needinfo?(davofanmail)

Comment 10

3 months ago

Ran some comparative profiles. Hopefully, I did it right. The two file names should make it clear which profile is which...although I'm not clear how to post the files as attachments to this comment. I'm just putting them at the top of the bug report.

Flags: needinfo?(davofanmail)

Comment 11

3 months ago

Comment 13

3 months ago

Forgot to mention that both the Win10 and Win7 boxes are i7 chips at around 2.4 GHz.
However, the Win7 box is a third-generation i7 chip, and the Win10 is eighth gen...which might mean different libraries.
Since CPU usage does not appear to be the issue (while the Win7 box is waiting, FF CPU is ~4%), not sure how relevant CPU speed is to this issue.

(In reply to David Taber from comment #10)

Ran some comparative profiles. Hopefully, I did it right. The two file names should make it clear which profile is which...although I'm not clear how to post the files as attachments to this comment. I'm just putting them at the top of the bug report.

In the future you can use the option to share a URL of the profile but I can also upload the ones you provided.

I uploaded the problematic Win7 profile at

So I see 96% of of the samples being spent in nsLayoutUtils::PaintFrame for passwordManager.xul:

mozilla::PresShell::Paint(nsView *,nsRegion const &,unsigned int)
PresShell::Paint chrome://passwordmgr/content/passwordManager.xul
nsViewManager::ProcessPendingUpdatesForView(nsView *,bool)
void nsRefreshDriver::Tick(struct mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, class mozilla::TimeStamp)

and I don't see passwordManager.js at all which aligns with comment 8's suggestion that this isn't related to bug 1429560.

Just to double-check you don't have some unusual persisted <tree> value causing some inefficiency, can you rename xulstore.json to xulstore.json.bak in your profile folder while Firefox isn't running? Then see if the problem still happens. (You can put the file back afterwards as it keep tracks of positions and sizes of UI). You can access the profile folder from the about:support URL.

Thanks for providing the information :)

Flags: needinfo?(davofanmail)

Comment 16

3 months ago

OK, ran the experiment with the xulstore.json file--no difference.
I guess I'm surprised that bug 1429560 would apply to a local disk (which this is), but as this symptom appears to be unique to Win7 (with exactly the same disk configuration) who knows...

Flags: needinfo?(davofanmail)

OK, thanks. I'll move this so the layout team can see if there is anything interesting in the profile: (see comment 15)

Component: Password Manager → Layout
Product: Toolkit → Core

Comment 18

3 months ago

FWIW all machines have GPUs, but they are different speeds. I can't imagine FF exercising the GPU, but stranger things have happened.

Priority: -- → P3
Whiteboard: [layout:triage-discuss]
Whiteboard: [layout:triage-discuss]

Bug 1549799 is replacing this UI in Firefox.

Closed: 4 days ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.