Open ygoe opened 5 months ago
No code was adjusted related to timeout lock for 2.7.7. The timeout lock code is actually very simple. Set it to 5 minutes and check again.
Tried this:
So it seems like it won't be locked when minimised and unlocked through the browser extension.
I'll investigate that angle, thank you for narrowing
I couldn't reproduce the behavior sequence you show above with a timeout of 30 seconds with the debugger on. Everything seemed to work properly.
An hour or so later the database was locked eventually. Seems like the configured delay is exceeded by much.
That would imply something is triggering the timer reset for whatever reason. That is the only way it would extend past the configured time setting.
Could it be the browser extension asking the database as I randomly browse web pages?
I wouldn't consider this "activity" though.
There are only a handful of things that reset the timer:
if ((type >= QEvent::MouseButtonPress && type <= QEvent::KeyRelease)
|| (type >= QEvent::HoverEnter && type <= QEvent::HoverMove)
|| (type == QEvent::Wheel))
And if the applications settings are saved or reset, but you need to be interacting with the application to do that.
https://github.com/keepassxreboot/keepassxc/blob/develop/src/core/InactivityTimer.cpp#L42
Does this also cover the tray icon? I might occasionally hover that one when I'm using other icons or clicking on the clock/notification area. That would well explain things. I haven't watched that specifically.
Good question, it might. I'll check with the debugger. That would definitely make sense.
At least on Windows, hovering the tray icon does not trigger the inactivity timer reset. If you open the tray icon menu (right click) and then hover over the menu, the inactivity timer is reset.
Can you try these steps:
Now, after unlocking once, the database never locks again until maybe the main window is opened again or the tray icon menu is accessed as you described. But usually I don't need to do that. The global auto-type would restart the timer (because you'll be interacting with a window), but the browser add-on alone won't do that. That also means that repeated browser logins during an active idle timer will not prevent the database to be locked, maybe even between seeing the green fill button and clicking it.
Update to 2.7.8 and try again. I found a potential cause and fixed it.
I can confirm that the issue and described steps to reproduce are still valid with 2.7.8. Nothing has changed to this regard.
Sorry to ask ... but is there a chance that this setting is not available in the Linux (Debian, from the default repo) version?
Only ... I think it's still actually doing its job (annoyingly enough) ... but I can't seem to affect it. :(
Overview
The application setting "Lock database after inactivity of ... seconds" is no longer working. It appears to have an effect sometimes, but many times the database remains unlocked for much longer.
Steps to Reproduce
Expected Behavior
After 30 minutes, the database is locked.
Actual Behavior
Often, it remains unlocked.
Context
It used to work before 2.7.7 but I haven't watched this closely.
KeePassXC - Version 2.7.7 Revision: 68e2dd8
Qt 5.15.11 Debugging mode is disabled.
Operating system: Windows 11 Version 2009 CPU architecture: x86_64 Kernel: winnt 10.0.22631
Enabled extensions:
Cryptographic libraries: