Auto-Type Problems with @ in username

[rgloor]

Expected Behavior

When using Auto-Type, correct USERNAME should be inserted in Form:
eg: myname@mydomain.tld

Current Behavior

Auto-Type replaces the @ by a " , so it would enter a wrong USERNAME into the Form:
eg: myname"mydomain.tld instead of myname@mydomain.tld

Possible Solution

?

Steps to Reproduce (for bugs)

1. Go to "site" or app or what-so-ever
2. Put cursor into the first formfield (eg. for username)
3. Press Auto-Type Global HotKey
4. Select the entry

Context

Trying to insert credentials for login into accounts on websites.

Your Environment

• KeePassXC version/commit used: (can be found under Help -> About) :
  KeePassXC v2.1.0
• Qt version (e.g. Qt 5.3):
  Qt 5.6.1
• Compiler (e.g. Clang++3.6.0):
  N/A
• Operating System and version:
  openSUSE LEAP 42.2 (fully patched)

Note

It might be not KeePassXC itself, because it could be, that the behavior changed after the last upgrade of KeePassXC. But I am not absolutely sure.
However, you might still be able to track down the source of the problem and help fixing it.

[rgloor]

partially "solved"
I don't know what happened. All by a sudden, it worked again!
In order to test the KeePassXC Auto-Type-Function, I wrote a KeePassXC-DUMMY-entry for KWrite (text editor). And within KWrite, I started Auto-Type and that way could test and see what was handed over from KeePassXC.
Now, before shutting down the Notebook, I was closing down all apps and in the end just had the KWrite left. Out of curiosity, I just did another Auto-Type Test, and...
...and surprisingly, it was working again.

So the issue has disappeared for me for now.
But I am sure, the source of the problem is not yet solved.
Eventually my description can help you tackle down what happened.

I will still keep an eye on it and see, if I can get it to reproduce again.

[TheZ3ro]

From a code point of view, nothing changed in Autotype in the last version.
This is the function that replace the {USERNAME} keyword and this loop inject the username's key in the text field.

I can't reproduce this on my PC. I will leave the issue open with a "more info needed" tag, ok?

[rockihack]

This is a keyboard layout issue. Keepassxc and your system use different layouts.
Shift + 2 produces a @ character in US layout, but your system uses some other layout where Shift + 2 produces a ".

[phoerious]

Yes, autotype is bound to your keyboard layout. Are you using the app image? We had an issue here where the AppImage always used a US layout on Fedora, although it should have used an AZERTY layout. I was never able to reproduce it.

[phoerious]

Closing since we can't reproduce and it seems to be working for you again.
Most likely not a KeePassXC issue anyway.

[TheZ3ro]

I've experienced this the other day when my system layout was IT and Autotype sadly is US-only like @rockihack said.
Reopening this.

There is a method to change the autotype layout? If not we can close again

[rockihack]

I never said that autotype is US-only. It seems to be a bug in xcb autotype or your display server.

keepassxc/src/autotype/xcb/AutoTypeXCB.cpp

Line 223 in 1f6f7b6

else if (type == XCB_MAPPING_NOTIFY) {

[phoerious]

Problem seems to be that autotype sometimes doesn't respect the user's keyboard layout and then falls back to a US layout. But I have no idea why.
Maybe it has something to do with: https://bugreports.qt.io/browse/QTBUG-30911

[rgloor]

Still not fixed. Had problem again.
Yesterday, just installed KeePassXC v2.1.3. and it worked again.
After restarting the system this morning. Problem is here again.
Closed KeePassXC, restarted it again. Now working again..... but not having any clue, what will trigger the misbehavior again.
So issue is still open.

[rgloor]

Tracked it down a bit:
When I shut down my system (openSUSE LEAP 42.2), I usually leave KeePassXC running.
So when I start it up again, KeePassXC comes up as well after login.
What I found:

• When KeePassXC is started automatically, the keyboard mapping / layout is wrong (@ -> ").
• When I close KeePassXC and restart it again, everything works fine (@ -> @).

So when KeePassXC is starting within the start up process / login process of the system, it might initiate before the correct keyboard layout is defined.

Is there a startup / login sequence where KeePassXC might wait for a certain event to be passed before it starts up or defines the keyboard? Just a thought.

[droidmonkey]

If you want to wait for events, use udev or similar. I would just add it to the end of your .bash_profile or equiv file.

[phoerious]

I really think this is tied to the Qt bug I linked above. KeePassXC gets the correct layout when it is already set, but when it changes during runtime, KeePassXC doesn't notice.

[frostasm]

I have similar problem with "Ukrainian" keyboard layout and I wrote a small fix. Before "auto-typing" procedure keepassxc change the system layout to "English" and after "auto-typing" return back the original layout.

[droidmonkey]

That's great! It would be even better if the user could set a desired keyboard layout in settings. Default being "us".

[frostasm]

@droidmonkey I can prepare PR with related changes. But at the moment my fix is relevant only for Linux, what about the others operation systems?

[frostasm]

And one more note, method with changing system keyboard layout only works assuming that the "us" layout will be the first in the list of layouts, otherwise, changing the layout does not help :(

[droidmonkey]

This definitely requires more discussion and investigation, but i think we are on the right track. I have not heard any complaints about autotype on windows or mac with alternate keyboards. This might be a linux only change and can be ifdef'd as such.

[stratacast]

I can confirm this is not an issue on Windows 10, but is an issue with all my Linux boxes

[stefan123t]

@phoerious yes, I just wanted to state clear that I have mistaken TCATO with the simulated keypresses, i.e. keycodes used for normal auto-type.
These X11/XKB keycodes already looks a bit "obfuscated" and this is the probable cause for the active setxkbmap keyboard layout setting to mingle with the interpretation of those keycodes issued by KeepassXC converted into characters when typed into the target application window.

[hifi]

@stefan123t If possible try #6247 if it helps with the wrong layout being used. It's not yet ready for merge but it should have the right idea how to solve that.

I was looking for information about the layout change hotkey (like alt-shift) not working after auto-type has been issued.

[hifi]

I believe both issues are now fixed with #6247. If anyone could test it that would be great!

[stefan123t]

@hifi I tried to checkout the pull request #6247 using github but did not succeed.

$ /snap/bin/gh pr checkout 6247
fatal: Unable to find remote helper for 'https'
exit status 128

How do I best checkout your PR and commit selectively ?

[droidmonkey]

https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally

[stefan123t]

@droidmonkey thanks for the pointer, I got it to checkout with the debian packages of github and following the description on the your wiki to install all the qt5 dependencies it compiled fine.
Is 2.7.0 going to stay this way or did I forget some Qt compile options ?
For me it takes a lot of screen estate (even in View > Compact mode!) and the native Linux Mint/Debian version 2.4.3 is a lot less space hungry.

@hifi, thanks for the pull request #6247.
Regarding #324 it does auto-type the correct sequence for all us, de and fi keyboard layouts I configured.
I.e. there were some additional questionmarks raised by @ohnonot regarding a third layout could be detected correctly earlier in this issue.

$ setxkbmap -print -verbose 10 | grep '\(layout\|xkb_symbols\)'
layout:     us,de,fi
	xkb_symbols   { include "pc+us+de:2+fi:3+inet(evdev)+group(shift_caps_toggle)+group(lalt_lshift_toggle)"	};

us: myname@mydomain.tld passwordwithZ,Yand@
de: myname@mydomain.tld passwordwithZ,Yand@
fi: myname@mydomain.tld passwordwithZ,Yand@

@hifi, I am looking forward whether this will also solve the issue with the Alt+Shift key combo for switching the keyboard layout not working sometimes ?
I do experience this also from time to time, but could not attribute it to the Keepass auto-type option yet.
I though it has something with a Citrix client who does not always behave quite well.
Do you have a test case, where this is reproducible and is there an issue ?

[hifi]

#6247 should work with any number of layouts that X can simultaneously have enabled. It will also prefer your current layout during typing but will switch it on-the-fly if a symbol is only found in some other layout. If you have an indicator on some panel which layout is active and you have slow enough typing delay for Auto-Type it should be visible that the layout is changing automatically on demand.

However, it does not work if you try to use a symbol that is not within any of your configured layouts but that's a tradeoff I'm willing to make for code cleanliness. It makes issues like #3422 an edge case that will regress slightly as I couldn't find a keyboard layout combination that had all of the symbols used in the example and it will instead just skip/ignore them. I did get most of them out by adding a couple of large layouts.

I haven't been able to reproduce the layout switch toggle not working after Auto-Type consistently enough I could debug it. Though if #6247 happens to fix it as well I'm not very keen to debug it further either so testing it for longer periods of time where you usually get the layout switch breaking issue would be nice to know.

I hope we can get most Auto-Type issues on Linux that are fixable done for 2.7.0 as Auto-Type has received a major overhaul in UX as well.

[the-wolfman]

guys, very good to hear that. I am out of my depth here, so please excuse a frank question:

Does this also affect the issues with auto-typing into a virtualbox or the like instance running linux guests?

No clue how linux handles keyboard layouts at boot time. Something like grub config during e.g. password entry for luks encryption and session manager config at login screen?

[hifi]

@the-wolfman If you had problems with incorrect characters typed in VirtualBox then it may help. I added an AppImage download as a comment to #6247 if you can test it.

[the-wolfman]

ok, missed that AppImage. Will try on Wednesday as I am travelling and need to set up a test host. On a side note, most of the problems seem to occur when using Windows as a host, as mentioned in issue #1833, which I can confirm. If, by chance, you've created a Win64 Portable as well, I can also test that.

[droidmonkey]

The fixes made by Hifi only apply to linux

[stefan123t]

@the-wolfman this issue spplies to Linux platform and Auto-type in native X windows only.
That is the same symptom could be experienced on any combination of differing keyboard layouts used in VMs, etc. but as the KeepassXC outside a VM can not easily know the layout set and used inside the VM, a mapping is not possible, except you are using the same within and without.

[the-wolfman]

Thanks, your comments nudged me in the right direction. Still way out of my depth though.
Anyway, I followed up on the issues I encountered in that context and am convinced that on my linux host, my kind of mixed locale settings, especially the combination of LANG=en_US.UTF-8 with other languages in the LC_% values, as well within and between host and virtual instances was causing the trouble. I worked around it intuitively till now without understanding it.
fwiw, out of curiosity I also did some tests with a Windows Virtualbox host and strongly believe the overall way keypresses are treated by Virtualbox on Windows is making the difference. Some passwords, even simple base(x) variants or numbers can fully lock up keyboard input for Virtualbox instances without them even getting to the guest.

[mizapf]

I noticed that from time to time, my username or password was incorrect when using autotype. When I found this bug report, I checked a bit deeper and saw that autotype actually dropped all occurances of "z" in the username or password. As you can see, my username contains a "z", and I am of course using a German keyboard layout, so I cannot avoid this issue by e.g. choosing another password.

However, the problem never occurs from the start. When I launch my Plasma/KDE system and have KeepassXC autostarted, there is no problem, all characters are filled in, including the z. After some unknown time of use, the issue shows up, and since I only notice it on the next attempt to fill in a login form, I don't know what causes the problem.

In that case I have to completely stop KeepassXC and restart it. Then, autofill is working again.

[hifi]

@mizapf can you reproduce the issue with a 2.7 snapshot? Linux Auto-Type is completely revamped in it.

[stefan123t]

Dear Michael,
the problem is solved for the 2.7 versions by the Patch from Toni @hifi

The problem occurs in previous version if you have multiple keyboard layouts (english, german, etc.), which you can switch using the Desktop environments helper tasklets (the flag symbol) or eg. Shift+Ctrl as a hotkey on some systems.

Please make sure to use only one or at least the same, primary keyboard layout throughout the KeepassXC usage, in case you are troubled by this problem. Or upgrade to the latest keepassxc 2.7 snapshot release where this is fixed.

You can always check which keyboard layouts are currently set:

setxkbmap -print -verbose 10 | grep layout

Kind regards,
Stefan

[Nishi]

Was this auto-typing issue resolved for all OSes, i.e. for Windows 10 as a host OS as well?

KeePassXC 2.7.1 doesn't work for me in this regard - in contrast with KeePass Classic as old as version 1.31.

[droidmonkey]

This was a Linux only bug. On windows if you type into a virtual machine you'll have problems, otherwise it works without issue as far as we know.

[dok18]

@stefan123t @droidmonkey

This is happening to me with newest version (KeePassXC-2.7.1-x86_64.AppImage). I am on Ubuntu.

It does not happen with KeePassXC-2.5.3-x86_64.AppImage which I used until today.

Layout:
$ setxkbmap -print -verbose 10 | grep layout
layout: at

I have no other keyboard layouts or whatsoever. Basicly is uses for some rease on QUERTY instead of QWERTZ.

Any ideas what to do here?

[droidmonkey]

@hifi

[hifi]

Umm, try running setxkbmap once and see if it happens, though there should be a workaround for that in KeePassXC that avoids it.

[dok18]

Running

$ setxkbmap de -option grp:alt_space_toggle

"fixes" this. Still interesting, that I dont have this problem with KeePassXC-2.5.3-x86_64.AppImage, but it exists with KeePassXC-2.7.1-x86_64.AppImage.

[stefan123t]

@dok18 sorry for being late to the party/issue:

Would you mind running the following before and after your workaround in order for us to understand what has been changed in your xkbmap ? Please make sure that before the workaround the problem still is reproducible. Thanks

$ setxkbmap -print -verbose 10

Also please make sure to give us some detail about your system e.g. using

inxi -F

other than that we may be able to get some more information from looking at the results of your current xkblayout-state (you need to compile that from source)

xkblayout-state print "%s"