Autotype broken on keyboard layouts with dead keys

[Edgarins29]

Hello,

It looks like autotype is broken on keyboard layouts with dead keys, it worked in previous version.

trying on current version with US keyboard layout password pastes as: p!nbnTabz8vVXQV3Qrk6g#@!

And the same password using Latvian with apostrophe dead key layout. 'p!nbn"Tabz8v"V"X"Q"V3"Qrk6g#@!

It looks like it always insert unnecessary symbols before Uppercase characters.

Using Linux.

From my understanding this is probably the PR commit which caused the issue: Auto-Type: Map ASCII dead keys on Linux #7614 Maybe this PR misses handling apostrophe as dead key but it's just a guess.

Best regards, Edgars

[hifi]

Please don't remove the issue template. Are you running 2.7.0 or 2.7.1?

[Edgarins29]

KeePassXC - Version 2.7.1 Revision: 5916a8f

[hifi]

I can reproduce this with said layout, looking into possible fix. Was the previous version you had 2.6 or 2.7.0?

[Edgarins29]

2.6.6 was my previous version. Then updated directly to 2.7.1.

[hifi]

I figured out the underlying issue but it's not an easy fix. It did reveal two issues with the new Auto-Type code where one is trivial and other requires implementing dead keys properly.

[Edgarins29]

Hello,

After upgrade from Ubuntu 20.04 to 22.04 there was also update on dead key layouts in Latvian. There is a new layout which SHIFT+DEADKEY doesn't spawn double quote right away, but let's you enter alternate upper-case symbols while holding shift. It's called Latvian (apastrophe, dead quotes) - on that one the Auto-Type seems to working properly. It might also explain why passwords which have upper-case characters have " double-quotes before symbols as it simulates original apastrophe variant.

I also had disagreement with fellow Latvian apastrophe users that it's not logical behaviour apastrophe did, so the new one was created. The new one matches F key variant, ~(tilde) variant and ALT key variant in dead key behaviour. So maybe it's not per-se problem with auto-type but strange behaviour of simple apastrophe variant.

[phoerious]

Is the original issue still valid?

[komandar]

Yes it is. There are also problems with the German keyboard layout and every 2nd saved password unfortunately cannot be inserted via Auto-Type. It would be great if someone could fix the problem.

[rotanid]

this is a really annoying issue, for us it primarily manifests in the form that uppercase letters are randomly typed as lowercase...

[ghost]

What happens to me is that in some combinations, when I auto-type username and password, it changes the '^' for a '&'. It's weird because if I auto-type only the password this doesn't happen.

I use Spanish (Spain) layout within Ubuntu 23.04.

[lyallp]

Mine is a weird one, not sure if this is a KeepassXC issue or a Windows 10 issue or a VirtualBox issue, but here goes.

Using KeePassXC 2.7.5 running under Linux (Gentoo, fully up to date), Auto Type to a Linux window works just fine.

However, AutoType into a VirtualBox 7.0.10 guest, which is Windows 10, fully patched up, and the AutoType replaces the less than < symbol with the \ symbol.

I can see this because I run up Notepad in the windows guest and autotype into Notepad.

I use a password which has many case shifts (upper, lower, etc) and this breaks my password.

I have gone into Windows 10 settings and everywhere I can find I have turned OFF the multiple SHIFT press features.

I have tried this with two different Windows 10 Guests and a WIndows 7 guest. The behaviour is the same.

[Auronius]

Hello! I still have this bug on KeePassXC 2.7.7. Two years passed, but this bug still has not been fixed. Why?

[dridi]

I have been working around this specific problem ever since I ran into failing auto-types, and subscribed to this issue when the last comment was https://github.com/keepassxreboot/keepassxc/issues/7881#issuecomment-1282800969.

After reading this:

I figured out the underlying issue but it's not an easy fix. It did reveal two issues with the new Auto-Type code where one is trivial and other requires implementing dead keys properly.

I have forever been itching to ask why it worked before, which commit introduced the regression, and what the two problems are. Not that I could personally do anything about it if I knew more, I would probably be lost in this code base, but it would satisfy my curiosity.

Long live the dead keys :vulcan_salute:

[lyallp]

Minor Update.

KeepassXC 2.7.6 built on Gentoo Linux, fully up to date, Intel CPU, Xorg Windowing system, Fluxbox Display Manager.

Works just fine with native apps in Linux - such as emacs or browser.

QEmu Virtual of Win 10 fully up to date.

Take my word for it, in the following examples, my passwords have the tick character in them which is used to mark 'code', so the following text looks a bit weird (bold and such)

The password in Notepad, inside the Windows 10 VM -

$^A{YfMsLJ+7'3[=fH#^!)?9_`Vq9"R":)d'7}Vn4}>/E(v5Pe=@x2\z/,rU$75 (KeePassXC) $^A{YfMsLJ+7'3[=fH#^!)?9_`Vq9"R":d'7}Vn4}>/E(v5Pe=@x2\z/,rU$75 (Guest VM Notepad)

Win 10 Guest, fully up to date, in VirtualBox 7.0.12 is even worse

$^A{YfMsLJ+7'3[=fH#^!)?9_`Vq9"R":)d'7}Vn4}>/E(v5Pe=@x2\z/,rU$75 (KeePassXC) $^A{YfMsLJ+7'3[=fH#^!?9_`Vq9"R":d'7}Vn4}|/Ev5Pe=@x2\z/,rU$75 (Guest VM Notepad)

Ubuntu Guest in QEmu is catastrophic - SHIFT keys don't work! This includes using QEmu-viewer as well as the QEmu-Manager, both have the same issue.

$^A{YfMsLJ+7'3[=*fH#^!)?9_Vq9"R":)d'7}Vn4}>/E(v5Pe=@x2\z/,rU$75 (KeePassXC) 46a[yfmslj=7'3[=8fh361/9-vq9'r';d'7]vn4]</ev5pe=2x2\z/,ru475 (Text Editor)

I have no use for accents so I have not tested this.

I should mention that I use KeePassXC on Windows 10 through Microsoft Remote Desktop to Azure Remote Desktop and Remote Virtuals with no issue whatsoever, it's ony this 'corner' case of guests in various Virtuals under Linux that has a problem. I report this because it's there, not because it is affecting my day to day work.