Linux/Xorg/XFCE: Autotype not reacting for every window

[sfuhrm]

Overview

The behavior of the auto type hot key is different in how the windows it reacts in were created. My best guess is that this is a permission problem, but I don't see any error messages.

Steps to Reproduce

1. Open keepassxc
2. Take a XFCE-Terminal (opened by the xfce session manager on startup)
3. Press autotype hotkey
4. Cursor blinks, nothing happens

Now comes the interesting part: It works for starter-generated windows or windows created with the "File/New Window" menu.

Expected Behavior

1. Open a XFCE Terminal
2. Press autotype hotkey
3. Autotype shows up. If interaction with the OS fails, I'd at least expect a popup with an error message.

Actual Behavior

The cursor is blinking, but nothing is happening. Reassigning the autotype hotkey makes the behavior move with the new key assignment.

Context

KeePassXC - Version 2.6.3 Revision: beae186 Distribution: AppImage

Qt 5.15.2 Diagnosemodus ist deaktiviert.

Betriebssystem: Debian GNU/Linux 10 (buster) CPU-Architektur: x86_64 Kernel: linux 5.9.0-0.bpo.5-amd64

Aktivierte Erweiterungen:

• Auto-Type
• Browser-Integration
• SSH-Agent
• KeeShare (bestätigtes und unbestätigtes Teilen)
• YubiKey
• Secret-Service-Integration

Kryptographische Bibliotheken:

• libgcrypt 1.8.1

Operating System: Linux Desktop Env: XFCE Windowing System: X11

[droidmonkey]

Are you using a hotkey that could be swallowed by the terminal window? There are no permission restrictions for autotype on Linux unless, perhaps, you are using firejail or similar.

[sfuhrm]

No, the terminal (and thunderbird) window is not using a hotkey. It is clearly visible that the app window receives something, but not the original event (cursor blinks). I have not installed a security application like firejail.

Is the autotype hotkey handling only installed for windows that are created AFTER keepassxc was started?

Any clue on how to diagnose this further?

[droidmonkey]

Unfortunately I don't know what else to look for. X11 is an open system, its definitely not permissions related. The key handler has nothing to do with when a window is opened. If the app window receives something then try another hotkey like CTRL + SHIFT + J. I'm generally unsure if the problem is the hotkey detection or the aurotyping itself. In the application settings, enable "always ask before performing Auto-Type" to confirm if the hotkey is being received by keepassxc.

[sfuhrm]

If the app window receives something then try another hotkey like CTRL + SHIFT + J.

Tried that. The problematic application window cursor still blinks when pressing this hotkey.

I'm generally unsure if the problem is the hotkey detection or the aurotyping itself. In the application settings, enable "always ask before performing Auto-Type" to confirm if the hotkey is being received by keepassxc.

I activated that. On most windows, I'm seeing the auto-type requester.

I've started recording X11 events with

xinput test-xi2 --root

the cursor blinking described above comes from a FocusIn / FocusOut X11 event:

EVENT type 9 (FocusIn)
    device: 3 (3)
    windows: root 0x1c8 event 0x1c8 child 0x0
    mode: NotifyGrab (detail NotifyInferior)
    flags:  [same screen]
    buttons:
    modifiers: locked 0x10 latched 0 base 0xc effective: 0x1c
    group: locked 0 latched 0 base 0 effective: 0
    root x/y:  1243.00 / 499.00
    event x/y: 1243.00 / 499.00

it actually looks like Keepassxc is capturing the key, wants to open a requester (or bring the keepass app to the front), this leads to a focus change. But keepassxc fails with something (no requester/popup showing).

When the pressed key is not the hotkey, then there are no FocusIn/FocusOut events. So I think the FocusIn/FocusOut events come from keepassxc capturing the hotkey and trying to change focus somehow.

Is there a debug mode where I can get more information from keepassxc?

[droidmonkey]

If you have confirm every auto-type activated then there is no way KPXC is receiving the key press. There are no alternative code paths between the keypress capture and KPXC showing the auto-type selection dialog (or a message that no entries were found). It must be getting intercepted by something in your system.

[droidmonkey]

I do note that if you do not acknowledge the prompt indicating there are no entries found then the cursor blinks and nothing happens. The original prompt stays in the background. Make sure you close/ack all prompts and try to reproduce.

[sfuhrm]

Just re-checked. Yes, the auto-type prompt window is closed between the tests. This would have been a good explanation. The blinking also happens when keepassxc is the window with mouse/keyboard focus (what it wasn't).

[sfuhrm]

To get out of the mist, I compiled a keepassxc version with a little bit more debug output.

This is the condition that exits the AutoType::performGloabalAutoType() method in the error case:

    if (m_windowTitleForGlobal.isEmpty()) {
        m_inGlobalAutoTypeDialog.unlock();
        return;
    }

[sfuhrm]

XGetWindowProperty() returns BadRequest (== 1) for the problematic windows.

[sfuhrm]

Found the origin of the problem. This do-while-loop in AutoTypePlatformX11::activeWindow() tries to resolve some parent window, but the loop assigns NULL to the window variable because parent is NULL. This variable gets passed to XGetWindowProperty() later on (see above) which fails then.

[droidmonkey]

Great, I'll add this to my Auto-Type pr

[sfuhrm]

@droidmonkey Nice :-). Other tools like Google Chrome also have problems finding Windows like this. I'm not sure whether it's a bug in X11 or in the X11 client(s).

[droidmonkey]

After diving into the code for this I found it is much harder to solve this than I thought. The actual failure is in the way we determine if a window handle is to a "top level" window. I couldn't find a good consistent way to do this in X11 docs. Anyone have ideas?

[droidmonkey]

OK I think I found a fix. Can you guys compile the PR linked just above here and see if you can find your windows?

[sfuhrm]

Hi @droidmonkey thank you very much for your effort! I have compiled and tested the develop branch that contains the new code. Unfortunately the behaviour has not changed. There's a flickering, but nothing else. Do you need some more info?

[droidmonkey]

That is unfortunate. Can you provide screenshots and output from xprop regarding the window that is not working correctly?

[sfuhrm]

Well, this is looking very very like a bug in xorg. xprop does return no result when pointing to a problematic window. When pointing xprop to a ok-ish window, everything is fine.

keepassxc is probably doing everything right.

I'd say we close this bug and I try to figure out what's wrong with my X installation.

Thanks for your help, @droidmonkey !

[droidmonkey]

Yah if xprop fails then there is definitely nothing we can do.

[the-wolfman]

Are you using a hotkey that could be swallowed by the terminal window? There are no permission restrictions for autotype on Linux unless, perhaps, you are using firejail or similar.

Just a note for users running into this: Using Virtualbox with "Auto Capture Keyboard" selected in "Preferences - Input" does exactly that, it swallows the hotkey. Took me a while to find out as this setting "sneaked in" during an upgrade.