Global auto-type shortcut does not prompt for login if database is locked

[anshulbajpai]

Currently, if I want to auto-type password using the global Auto-Type key and if the database is locked, then nothing happens.
Then I have to go and unlock the database and then return back to my window and press Auto-Type key there.

It'll be nice to prompt to unlock the database (if locked already) if we hit the Auto-Type key.

Operating system: MAC-OS
CPU architecture: x86_64
Kernel: XNU

[quinncomendant]

I think keepassxc tries to do this, but the behavior is pretty wonky. If my DB is locked and I hit the auto-type key, a second window opens, also titled Unlock Database, with the same fields as the main window (Password, Key File, etc), like this:

This second window doesn't come to the foreground (in the screenshot above I've hidden the browser window that was at front when I hit the auto-type key), so you still have to switch to keepassxc manually. However, if you use ⌘-tab to switch back to keepassxc, it brings the main window to the foreground, and if you login there, the second Unlock window remains in the background, like this:

If you close the second unlock window (e.g., by clicking the little red close button in the top left corner), it closes, but also the database in the main window closes (taking you to the "Welcome to keepassxc" screen). This doesn't happen if you click the cancel button in the second unlock window.

So, there's lots of unexpected and not-ideal behavior happening here.

This could be simplified:

1. User hits the auto-type key
2. If the database is locked, just bring the main window to the foreground and place the cursor in the password field.
3. After the database is unlocked, resume with the auto-type function.

That's how it should work, right?

[anshulbajpai]

@quinncomendant - I believe you are right. I have seen the password unlock screen sometimes when I cmd+tab between windows. You are right that it doesn't come into the foreground.

If KeePassXC behaves as you described towards the end of your previous comment, it'll be a better UX.

[FeralBytes]

Maybe Linux Specific - After pressing the auto-type shortcut, KeePassXC does correctly prompt to unlock the database if locked; but that is it; then it goes away. It never auto-types the password. Until I press the Auto-type shortcut keys again. It would be ideal if it unlocked and then performed a search in order to auto-type, without having to press the shortcut again.
Should this be a separate issue?

[adatum]

@FeralBytes What version of KeepassXC and Linux are you using? For me with v2.2.0 on Ubuntu 16.04 32-bit, using the Auto-Type shortcut when the database is locked brings up an Unlock Database window into focus, and after typing the master password, automatically performs the auto-typing without further prompting. This is exactly the behavior I would want and expect.

One note is that if there are several databases available, it does not request to unlock all of them, so it may fail to find an entry if the relevant entry is stored in a still-locked database.

[phoerious]

The unlock window should stay on top. Maybe the window hint isn't fully working on macOS.

[FeralBytes]

@adatum KeePassXC v2.2.0 via a .deb from github latest release. Linux Mint v18.2 64-bit Kernel v4.8.0-58-generic Desktop Environment is Cinnamon v3.4.6. I have tried the auto-type with a locked database on several types of windows. To include: gnome-terminal, terminator, FireFox, Chromium. and Update Manager. Pressing the Auto-Type does bring up the unlock screen, but upon entering my password and pressing enter the unlock screen goes away; but the password is not auto-typed. Only 1 database is open.

[TheZ3ro]

@FeralBytes how do you have configured the autotype? Have you enabled the "Use entry title to match window in global autotype" option ?

[FeralBytes]

@TheZ3ro Auto-Type is set up as ctrl+alt+b. I had "Use entry title to match window in global autotype" option disabled. So I enabled it, and tried using Auto-Type from a locked database on both the terminal and FireFox. Again though the window pops-up to unlock the database, after pressing enter the window goes away and Auto-Type never occurs. Until I press the shortcut again; at which time it works and correctly auto-types into the window. Even with the option enabled or disabled.

[FeralBytes]

@TheZ3ro today; I unlocked the database with auto-type sequence and it worked correctly as you explained with out a second press of the sequence so I will be investigating this further. But for now can probably be ruled out as my system only configuration issue. Kind of crazy that it fixed it's self though when I did nothing that I know of; except applying new updates.

[nmschulte]

I experience this issue from time-to-time (at least once a session). Sometimes after unlocking the database (via global auto-type shortcut, with the database locked; auto-lock after some seconds), KeePassXC does not perform the auto-type. Issuing the global auto-type shortcut again works as expected.

I am running Debian GNU/Linux Sid/unstable, X11 w/ i3wm via user-supplied Xsession (~/.xsession) via SDDM.

$ aptitude changelog keepassxc/sid
keepassxc (2.2.2-1) unstable; urgency=medium

  * New upstream version 2.2.2
  * Add missing dependency on qttools5-dev (Closes: #882306)
  * Drop desktop_file_comment.patch and rebase others
  * Bump Standards-Version to 4.1.1

 -- Julian Andres Klode <jak@debian.org>  Tue, 21 Nov 2017 11:12:12 +0100

[FeralBytes]

I would also like to update that the issue still persist intermittently for me as while.

[nmschulte]

I did some digging into my issue. What I found was that AutoType::performGlobalAutoType was returning (without performing an auto-type) because the "windowTitle" (plugin->activeWindowTitle()) was empty.

https://github.com/keepassxreboot/keepassxc/blob/develop/src/autotype/AutoType.cpp#L194

I'm digging into why AutoTypePlatformX11:windowTitle is returning an empty string.

---

The issue appears to be some sort of race condition -- sometimes AutoTypePlatformX11::activeWindow() returns 0 during AutoType::performGlobalAutoType. I've only ever seen this when it was signaled via the UnlockDatabaseDialog (DatabaseWidget::unlockDatabase), never from an unlocked database (DatabaseTabWidget::performGlobalAutoType).

---

Below is the output with some custom logging added (see attached patch). Lines of the format ** WORDS HERE -- were notes I typed to the console manually, everything else is logging. Relevant function calls are prepended with an empty line followed by the class/method name and arguments.
The failure is presented in the first attempt (TRYING WITH LOCKED DATABASE), where you can see the call to AutoTypePlatformX11:windowTitle (from AutoType::performGlobalAutoType's AutoTypePlatformX11::activeWindowTitle call) is done with window == 0 (xlib: None window) not the browser window (31457326, logged immediately after the activeWindowTitle call).

Digging further, it seems the AutoTypePlatformX11::activeWindow is determined as None (0) when the call to XGetInputFocus returns a window of 1 (PointerRoot) (because XQueryTree with this window id will resolve to 0/None, which exits the do/while loop). This indicates some kind of race condition to me, between KeePassXC and my window manager (i3wm)/xserver. PointerRoot doesn't seem like it would resolve to my browser, but instead some i3-managed window.

nmschulte@desmas-l:~/src/keepassxc$ ./src/keepassxc

** TRYING WITH LOCKED DATABASE --


DatabaseTabWidget::performGlobalAutoType ()

DatabaseWidget::unlockDatabase (accepted =  true )
from unlockDatabaseDialog
dbList length:  1

AutoType::performGlobalAutoType (dbList =  (Database(0x556497ea5420)) )
inAutoType:  false

AutoTypePlatformX11::windowTitle (window =  0 , useBlacklist =  true )
windowTitle:  ""
activeWindow:  31457326

** DIDN'T WORK!! TRYING AGAIN WITH UNLOCKED DATABASE --


DatabaseTabWidget::performGlobalAutoType ()

AutoType::performGlobalAutoType (dbList =  (Database(0x556497ea5420)) )
inAutoType:  false

AutoTypePlatformX11::windowTitle (window =  31457326 , useBlacklist =  true )
XGetWindowProperty -- title:  "Example [www.example.com] - Chromium"
blacklist check ...
windowTitle:  "Example [www.example.com] - Chromium"
activeWindow:  31457326

AutoType::performAutoTypeFromGlobal (entry =  Entry(0x556498043dd0) , sequence =  "{USERNAME}{TAB}{ENTER}{DELAY 1500}{PASSWORD}{ENTER}" )

AutoType::performAutoType (entry =  Entry(0x556498043dd0) , hideWindow =  QWidget(0x0) , customSequence =  "{USERNAME}{TAB}{ENTER}{DELAY 1500}{PASSWORD}{ENTER}" , window =  31457326 )

** WORKED!! TRYING AGAIN WITH LOCKED DATABASE --


DatabaseTabWidget::performGlobalAutoType ()

DatabaseWidget::unlockDatabase (accepted =  true )
from unlockDatabaseDialog
dbList length:  1

AutoType::performGlobalAutoType (dbList =  (Database(0x556497985f60)) )
inAutoType:  false

AutoTypePlatformX11::windowTitle (window =  31457326 , useBlacklist =  true )
XGetWindowProperty -- title:  "Example [www.example.com] - Chromium"
blacklist check ...
windowTitle:  "Example [www.example.com] - Chromium"
activeWindow:  31457326

performAutoTypeFromGlobal (entry =  Entry(0x55649800cf80) , sequence =  "{USERNAME}{TAB}{ENTER}{DELAY 1500}{PASSWORD}{ENTER}" )

performAutoType (entry =  Entry(0x55649800cf80) , hideWindow =  QWidget(0x0) , customSequence =  "{USERNAME}{TAB}{ENTER}{DELAY 1500}{PASSWORD}{ENTER}" , window =  31457326 )

** WORKED!!

logging.patch.NOT.txt

---

I wonder if this is relevant: https://stackoverflow.com/questions/31800880/xlib-difference-between-net-active-window-and-xgetinputfocus

[Krzmbrzl]

I'm experiencing the same issue as @FeralBytes and @nmschulte on Manjaro Linux with KeepassXC version 2.2.2 (Kernel 4.14.8-1).

If needed I'll of course provide further system information.

[LinuxOnTheDesktop]

I have the same problem - at least intermittently - on Linux Mint 19.1 Cinnamon. It's pretty annoying.
EDIT: actually, the problem occurs only if more than one database shows in KP's unlock window. Working out how to avoid that situation was harder than would be ideal . .

[droidmonkey]

The unlock dialog is properly shown in 2.4.0, however there still exists the bug of unlock and not finding the correct windows. That is already covered under #1216. Closing this one.