macOS: Auto-type hotkey doesn't focus the correct pop-up window

[blksith0]

Overview

Auto-type hotkey brings up both main window and Auto-type window, but auto-type window is not highlighted, forcing me to grab the mouse and click (either in the search-box or on the highlighted found entry).

Steps to Reproduce

1. Press auto-type hotkey (Ctrl+Alt+A for me)

Expected Behavior

Bring up only the auto-type window. Main window visibility is not needed.

Context

KeePassXC - 2.7.1
Operating System: macOS Mojave 10.14

[droidmonkey]

Do you have your focus on a password field prior to pressing the auto type hotkey? If so, that appears to be a macOS security "feature"

[blksith0]

No the focus is on the username field.
The Auto-Type window pops up but I always have to click it it in order to search (if not found) or select the entry that was found / double-click.

[stefansundin]

Hello. I wanted to chime in here and say that I also experience this problem. I don't know when it started but I don't think it has always happened.

As the original report states, maybe it is possible to keep the main KeePassXC window hidden? Maybe that would help?

I decided to record a video to show what is going on, just in case there's any confusion, and to conclusively show that it is not user error. I hit my Auto-Type shortcut (Control+Option+Command+Z) 25 times and in 4 cases the main KeePassXC window was focused instead of the Auto-Type window. I use the up and down arrow keys to demonstrate which window is focused. I feel like it usually happens more often than in this experiment, but maybe it just feels like it is happening more frequently because whenever it happens it is quite annoying.

Anyway, here's the video:

KeePassXC-Auto-Type-Focus-Issue.mp4

Here's my debug info:

KeePassXC - Version 2.7.6
Revision: dd21def

Qt 5.15.10
Debugging mode is disabled.

Operating system: macOS 14.1
CPU architecture: arm64
Kernel: darwin 23.1.0

Enabled extensions:
- Auto-Type
- Browser Integration
- SSH Agent
- KeeShare
- YubiKey
- Quick Unlock

Cryptographic libraries:
- Botan 2.19.3

[stefansundin]

I think there's a good chance this issue is the same as #8169. I read a comment (#8169 (comment)) and wanted to confirm that this behavior was introduced in 2.7.0. I downloaded both 2.6.6 and 2.7.0 and tested both and as suspected this issue was introduced in 2.7.0. This also rules out any changes that Apple might have made in the recent macOS updates.

I noticed that in 2.6.6 it takes a moment before the auto-type window is opened. Perhaps there's a simple race condition that triggers now that the auto-type window is opened much faster?

[droidmonkey]

Good observations, the major change made in 2.7.0 was to explicitly focus the window that was in focus when the Auto-Type shortcut is pressed. I recently found some idiosyncrasies with how we are handling the main window on macOS.

[kevenwyld]

Just want to say I'm also experiencing this issue on macos, exactly as it is in the video above.

KeePassXC - Version 2.7.9
Revision: 8f6dd13

Qt 5.15.11
Debugging mode is disabled.

Operating system: macOS 14.7
CPU architecture: arm64
Kernel: darwin 23.6.0

Enabled extensions:
- Auto-Type
- Browser Integration
- Passkeys
- SSH Agent
- KeeShare
- YubiKey
- Quick Unlock

Cryptographic libraries:
- Botan 3.1.1

MacOS Sonoma 14.7 (23H124)

[kytta]

@droidmonkey sorry to ping you, but why exactly was this closed "as completed"? I don't see any related PRs/commits, and the issue still exists

[droidmonkey]

No worries. Don't worry about the github verbiage, you get a choice between Completed and Not Planned. I can't replicate this behavior so it's not possible to correct. I also doubt this is a code problem on our end but more of a window behavior issue on macOS. We have spent a lot of time refining auto-type and we are on diminishing returns.

Possibly related:
#11217
#6489

[droidmonkey]

I am reopening to try adding a small delay that might allow things to settle before attempting to take focus in the autotype select dialog.

[kytta]

I also doubt this is a code problem on our end but more of a window behavior issue on macOS. We have spent a lot of time refining auto-type and we are on diminishing returns.

I see, thanks for clarifying!

Don't worry about the github verbiage, you get a choice between Completed and Not Planned.

Yeah, I know, but in this situation, I would choose "not planned". But for issues like this, there is no good wording 😂

[stefansundin]

I can't replicate this behavior so it's not possible to correct.

In these cases it might be better to ask for people that are able to repro to experiment and try to submit patches. Maybe add "hard to repro" and "patches welcome" labels. At least for a month or so before closing the issue.

I also doubt this is a code problem on our end but more of a window behavior issue on macOS.

We know that it did not happen before 2.7.0, so even if it is a bug in macOS there should be ways to work around it.

I am reopening to try adding a small delay that might allow things to settle before attempting to take focus in the autotype select dialog.

Great! I'm available to test builds and see if I can repro with your changes.

If your experiments are unsuccessful then I'm happy to open up the code myself and test various things. It could be useful to have your test branch for reference as well.

[droidmonkey]

I hear you but we aren't an enterprise software company. We have to balance time and attention on niche issues and betterment of the overall program. This issue has been open for 2 years and no offers for code changes or experimentation have been made. Adding a label won't change that.