Database unlock dialog doesn't reappear after dismissing with Escape key

[unimpededglare]

Overview

I've noticed that sometimes when I trigger my auto type shortcut (ctrl+alt+a), the KeepassXC window doesn't pop up. I think I've finally figured out when this happens.

Settings

"Settings -> User Interface", the following three settings are checked:

• Minimize instead of app exit
• Show a system tray icon
• Hide window to system tray when minimized

Steps to Reproduce

1. With the KeepassXC database open, manually lock your database by clicking the lock icon in the toolbar.
2. Press the X in the KeepassXC window to minimize it to the tray.
3. Press Ctrl+Alt+A (or whatever your autotype shortcut is) to bring up KeepassXC. As it is locked, it will ask for a password. Don't enter your password, instead just press escape to hide the unlock window.
4. Attempt to press ctrl+alt+a again, and the window will no longer appear no matter how many times you try the hotkey shortcut.
5. You can manually click the icon in the tray to bring up KeepassXC and this seems to reset the bug and temporarily fix it until the above steps are performed again.

Expected Behavior

The autotype shortcut should always popup the unlock window if the database is locked

Actual Behavior

The unlock window sometimes doesn't appear when triggering the autotype shortcut.

KeePassXC - Version 2.7.6
Revision: dd21def

Qt 5.15.10
Debugging mode is disabled.

Operating system: Windows 10 Version 2009
CPU architecture: x86_64
Kernel: winnt 10.0.19045

Enabled extensions:

• Auto-Type
• Browser Integration
• SSH Agent
• KeeShare
• YubiKey
• Quick Unlock

Cryptographic libraries:

• Botan 2.19.3

[droidmonkey]

Cannot replicate this at all, make sure your auto-type shortcut isn't being overtaken by the application itself (ie, its also an application shortcut).

[unimpededglare]

I changed my hotkey to something obscure to make sure it wasn't conflicting with something else (Ctrl+Alt+Shift+H) and I still have the same problem.

I started with a fresh portable installation and a new settings ini file to try to replicate this again with more detailed steps. It seems to need very specific steps to be triggered. This is the exact ini file I used except I removed the "Own" parameter in KeeShare before posting just to be safe:

[General]
ConfigVersion=2
UpdateCheckMessageShown=true
GlobalAutoTypeKey=72
GlobalAutoTypeModifiers=234881024

[PasswordGenerator]
AdditionalChars=
ExcludedChars=

[GUI]
CheckForUpdates=false
TrayIconAppearance=monochrome
MinimizeOnClose=true
MinimizeOnStartup=true
ShowTrayIcon=true
MinimizeToTray=true
MonospaceNotes=false

[KeeShare]
QuietSuccess=true

[Browser]
CustomProxyLocation=

Steps to Reproduce

1. With the settings configured to match the above, make sure KeepassXC is completely closed and not running in the background.
2. Relaunch KeepassXC and it should start minimized to the tray.
3. Double click the tray icon to open KeepassXC, and unlock the database.
4. Click the icon in the toolbar to lock the database.
5. Click the X in the window to minimize it to the tray.
6. Click on another application to bring it into focus (not sure if needed)
7. Type the autokey shortcut of Ctrl+Alt+Shift+H and press escape on the keyboard when the unlock dialog appears.
8. Attempt the autokey shortcut of Ctrl+Alt+Shift+H again, and the unlock dialog will not launch.

I can replicate it 100% reliably with the above steps. If you still can't replicate it, I can try it on a work computer tomorrow to see if perhaps something specific to my home computer is causing the problem.

I'm running Windows 10, so I don't know if the same problem would exist on Mac or Linux.

[droidmonkey]

Cannot reproduce even with that config and steps. Using Windows 11, 2.7.6.

[unimpededglare]

I did some more testing and I narrowed it down a bit more. The hotkey breaks for me when the unlock dialog box that pops up the first time is closed in specific ways.

1. Make sure database is locked and minimized to tray.
2. Double click tray icon to open it, but don't unlock, just hit the X to close the window again.
3. Type your hotkey to bring up the unlock dialog. Close this unlock dialog by either press the escape key or clicking the button that says "Close". Do not press the X in the corner of this dialog box, if you press the X then everything works fine and the hotkey will continue to work on future attempts.
4. Attempt the hot key a second time (nothing pops up for me)

If I close the unlock window that was triggered by the hotkey by doing one of the following, everything works fine and the hotkey doesn't break (I can even close the unlock window in future attempts with the escape key without causing a problem):

• Clicking the X in the corner of the window
• Alt+F4
• Clicking the icon in the top left corner of the window and going to "Close"

However, it seems to break if I close the window by doing the following:

• Pressing escape on the keyboard
• Clicking the button that says "Close" in the unlock window (the button next to the Unlock button)

It seems that the problem is tied back to the way the autotype unlock dialog box is closed the first time it appears (the method of closing the dialog on future hotkey triggers doesn't seem to matter, only the first time it is closed).

I'll give it a try at work tomorrow to see if I can replicate it on a different computer.

[unimpededglare]

Just tried this on my work computer (also Windows 10). I can reproduce it easily with the steps in my last post so it’s not something system specific.

[droidmonkey]

Unfortunately, I cannot reproduce this at all and thus cannot confirm a "fix" or that there is even a problem on our side at all. I am also fairly certain no one else who regularly use Auto-Type on windows is experiencing this as there are no other reports of this behavior.

[unimpededglare]

Thanks for looking into anyways. It’s been an annoyance and I figured it would be easy to reproduce.

As one final test, I started trying older versions of KeepassXC to see if perhaps this much was introduced with a particular version. It looks like it was introduced with 2.7.0, as I can’t replicate it with 2.6.6 but I can replicate it with 2.7.0.

I looked through the release notes but nothing stood out to me that could have been the cause though.

[droidmonkey]

Couple questions:

• is windows hello on / active during this?
• does auto-type work fine as long as you keep the database unlocked? (ie, can you cancel the auto-type selection dialog and have it come up again without issue)

[unimpededglare]

I don't use Windows Hello (finger print or webcam face unlock, correct?), so I'm going to assume it is not active on either computer I tested. Both computers are logged into with a username/password.
Auto-type works 100% fine as long as the database is unlocked. No matter how I dismiss the autotype window, it works perfectly fine as long as the database remains unlocked. The only time I can trigger the problem is when closing the unlock dialog that pops up asking for my database password.
There seems to be three different "windows" at play here:

1. The primary KeepassXC unlock window that comes up when you first launch KeepassXC that has the window title "VAULTNAME.kbdx [Locked] - KeepassXC". No problems occur after closing this window (although the escape key isn't an option to close this window anyways, so that's kinda a moot point)
2. The autotype window that shows up when your database is unlocked, no problems occur after closing this one either (even by closing it with the escape key). This window has the title ""Auto-Type - KeepassXC"".
3. The final window is the problematic one. It's what I refer to as the "mini unlock window". It looks similar to the window I mentioned in the first point, but just a smaller version of it. This window has the title "Unlock Database - KeepassXC". This is the window which will not appear again if I close it via escape or pressing the button that says "Close".

[droidmonkey]

The problem window is internally called the database unlock dialog. This is also used with the browser extension. Would you be able to setup integration with the browser and test unlocking through the extension? If that works fine under the same scenario then that would significantly narrow the code search.

[unimpededglare]

I installed the Firefox extension to test this. After connecting it to KeepassXC, I locked my database and minimized KeepassXC to the tray icon.

I clicked on the little icon in the username field on a website in Firefox to trigger the database unlock dialog asking for my master password. I pressed escape on my keyboard to hide the unlock dialog and then tried to click the username field icon again. The unlock dialog does not appear at all no matter how many times I click the username icon. I attempt my global hotkey and it also fails to show the database unlock dialog (which makes sense if both actions call the same dialog).

I tried the reverse as well. I reset everything and used the global hotkey to bring up database unlock dialog again, I once again pressed escape to "break" it. I then tried to click a username field icon in Firefox, and the database unlock dialog does not appear.

I can consistently break this dialog box in both scenarios.

I may have run into one piece of new information. After "breaking" the dialog, sometimes when I click the tray icon to bring up KeepassXC it will show both the main unlock window asking for the master password as well as the smaller "database unlock dialog" overlaid on top of the larger main window (essentially it pops up two windows, both asking for my master password). I can't consistently replicate this though. Not sure if that is helpful information or if it will just confuse things more.

When you press escape or click the button that says "Close", does it use a different method of hiding the database unlock dialog compared to if you click the "X" in the window or alt+F4? That seems to be the only difference between it breaking and not breaking.

[unimpededglare]

If I disable the setting "Show a system tray icon", then I can no longer break it.

[droidmonkey]

It seems like, for whatever reason, the unlock dialog is being hidden along with your main window. This shouldn't happen since the dialog is a totally separate window from the main window. Do you have any program that might be manipulating how windows behave?

I'm reopening because you can reproduce this so readily, but I am still not convinced this is a bug in our code.

[unimpededglare]

Do you have any program that might be manipulating how windows behave?

Yes on my home computer (Display Fusion), but nothing of my work computer. The work computer is fairly bare bones as far as software goes. I’ll see if I can test it on someone else’s work computer to see if I can still replicate it there.

[unimpededglare]

Tried another person’s computer at work (so bare bones I had the missing DLL error on startup so I had to install the runtime library).

I can replicate it immediately on the new computer. This computer is once again Windows 10.

Three computers now that I can replicate it on. Based on this, I think these are the only possible reasons you can’t replicate it at this point:

1. It’s a Windows 10 bug and doesn’t show on Windows 11.
2. My muscle memory is somehow excluding a step I am performing and I am not giving you accurate instructions.
3. Your muscle memory is doing something slightly different and you aren’t realizing it.
4. There is some common software on all 3 systems that is causing the problem and I don’t know what it is (I did a test and exited out of every app in my tray to see if that solves the problem, it didn’t)

This is not a big issue, just a minor annoyance having to click the tray icon every now and then to reset it to get it to work again.

If I come up with anything, I will post a comment, but I think I have exhausted everything on my end.

Thanks for volunteering your time for this project. It’s amazing software and we’re all very lucky that people like you exist in the world.

[droidmonkey]

@unimpededglare "great" news, I can now reproduce your issue! I will see what is going on with this. I was able to reproduce after I built 2.7.7 and installed it for testing. I cannot get it to happen 100% of the time, but there is definitely something going on.