Passwords are **not** locked automatically after period of inactivity

[charliemb2]

Title says it all.

Everything else is working perfectly.

Firefox version: 119.0 (64-bit) (latest)
OS: Windows 10 Pro Version 10.0.19045 Build 19045

Other things that could possibly affect PfP's operation:

1. I installed the host app in a non-standard location.
2. I'm running UBlock Origin in advanced mode.

Thanks

[palant]

I’ll need some more details. Do you use default autolock settings or did you change them?

Also, did you switch your computer into sleep mode in between? I’ve noticed that Firefox doesn’t count sleep time towards the timeout.

[charliemb2]

I use the default settings. I've not changed them or even clicked on the options.

I both have and have not put my computer to sleep with no difference as I've gone hours working and it remains open. The database is open right now and the last time I opened it was yesterday. I work on my computer all day.

Another possible angle: I have installed KeePassXC alongside PfP and also the KeePassXC-Browser extension, as I thought that was the plan ... to run them alongside so that I could use some of the other features of other KeePass apps. However, I've since changed settings so that XC is not started by default when I restart my computer. I've also disabled KeePassXC-Browser. So right now, there exists a db and only PfP can access it.

Side note: the databases were created with PfP-host to make sure I benefit from PfP-host's default security settings and also to ensure compatibility.

Side note 2: I can't say for sure if I've observed PfP ever timing out. But I have a feeling it hasn't.

[palant]

No, KeePassXC shouldn’t have any effect on PfP whatsoever.

PfP definitely does time out for me on Firefox 119. I use Linux however, will try it out on Windows eventually.

[charliemb2]

Looking at the source code, it appears you might have changed your timer function to use the browser's alarms API. If that is correct, and if this problem is specific to Firefox, then there is this:

[Inconsistency of the Alarms API](https://discourse.mozilla.org/t/inconsistency-of-the-alarms-api/108906)

[palant]

No, there would only be an issue if alarms don’t fire – yet this report doesn’t explain why it would happen.

[charliemb2]

Linux does not work for me.

I tried it in both Firefox and Vivaldi on MX Linux 23.1, which is based on Debian 12.2 "Bookworm." Both are the latest versions. Firefox comes installed by default on MX Linux 23.1. I separately installed Vivaldi using the MX Linux Package installer.

Specifically, I started with Firefox. Entered my master password. Used PfP to log into a site. I then waited 12 minutes. When I clicked on PfP it came up with the db open and ready to fill passwords.

I then switched over to Vivaldi and repeated the above process only I waited 15 minutes. Same result. PfP never asked me for my masterpassword and was ready to fill in and I performed the fill.

Of course the default timer setting is for 10 minutes and it is set, i.e., checked / enabled as it should be.

Since it fails in both browser bases (Firefox/Chrome), the problem is probably not related to the browser alarms API because ... what are the odds? Though, it is possible that this is hardware specific as I'm using the same machine in all cases where it fails

• Windows<-->Firefox,
• Linux<-->Firefox,
• Linux<--> Vivaldi.

(Edit: As a sanity check, I installed a separate timer extension in Firefox (in Windows 10). I set a timer for 5 minutes and took focus away from the browser. This worked. Though I don't know if the author of this extension used the browser's alarms API. I'll see if I can figure that out.)

[charliemb2]

Update. On Firefox in Windows it is now sometimes working, sometimes not. I've noticed that Firefox has been updated to 119.0.1 from 119.

Unfortunately, it is still not working in Linux.

I'll keep an eye on this and report as needed.

[charliemb2]

I'm now back to where I have access to another machine, also Windows 10 Pro and Firefox 120. This problem persists there after initially installing PfP and its host app.

This is odd because it resolved itself ¹ in the original computer above, same OS.

Footnotes

1. It was incorrect to say it resolved itself on the original computer. It is still intermittent on that one. ↩

[charliemb2]

In Linux, on a tower workstation computer, I had a perplexing experience where the database remained open through a reboot cycle.

Details
First I opened the db via PfP just to test that the timer was still not working. After 13 minutes I checked and confirmed that the db was still open. After about one hour some desktop icons in KDE / MX Linux were blank. I then rebooted the OS. When I came back I went immediately to a webpage and PfP and PfP didn't ask me to enter my master password. The db was still open from the previous boot / restart of the OS.

Should this not be alarming?

If it helps, this is a LUKS encrypted OS and home directory.

Please feel free to log this as a separate issue if you wish, or ask and I will log it.

[palant]

Are you certain that we are talking about the same browser extension?

[charliemb2]

I installed the PfP extension that's new and uses KeePass databases v4 which supports Argon (3.1.x..). In Linux I never installed the legacy version.

I have KeePassXC and 'XC-Browser installed but only one extension is enabled at a time under "Manage extensions." Only PfP was enabled and working before and after the reboot.

• The only possibility I can think of is that I somehow opened the db using the KeePassXC desktop application. But I don't remember doing so. I would only do that to log into that one website I reported in Issue Page using iFrame form => "The page has no password fields..." and saving an Alias doesn't work #143, to use XC's Autotype feature (since the clipboard isn't secure). But I had no need for that website on that day; I was creating live USB clones of the OS. Nevertheless, is that a possibility code-wise? I mean, even if I had used XC and left the db open, shouldn't PfP force me to enter my master password regardless of XC's status? The memory spaces should be separate, or must be.

If it matters, this occurred on an installed Linux environment (not live as it would have to be persistent) booting from an external USB 3.1 NGFF external SATA SSD. I doubt it matters.