Even though the KeePassXC version hasn't changed, AutoType is randomly "pasting" upper-case symbols (both capital letters and the "shifted" symbols above them on their keys) in both the username and password fields as lower-case. For example, an H might get Autotyped as an h, or a $ might get Autotyped as a 4. This happens regardless of the source username/password or target (browser or other app). When using it to sign into documents and sites, this results in a large percentage of invalid login attempts. Using the copy username/password process in KeePassXC and manually pasting to the target still works fine. This started with the Bazzite upgrade from version F43.20260217 to F43.20260303. Unfortunately, I don't know what the upstream Fedora versions changed to. The Bazzite people say they just use whatever comes down from Fedora. So, I loaded up the latest Fedora distribution in a Virtual Machine Manager VM and fully updated it. I installed the same (latest) KeePassXC flatpak as I use in Bazzite. The problem exists there as well. Reproducible: Sometimes Steps to Reproduce: 1. The easiest way to reproduce this is to Autotype into a word processing document (but you can do it anywhere else --like a browser). 2. Open a blank document and repeatedly hit your Autotype key combination (mine's CTRL-ALT-A). You might have to hit ENTER to get each "paste" on its own line. Just pick the same username/password entry from the KeePassXC data base each time. 3. Note that the Autotyped strings are not necessarily the same. I've had erroneously lower-cased symbols happen 1/3 to 1/2 of the time. Actual Results: A large percentage of Autotyped entries will randomly contain upper-case symbols that show up as lower-case. If you're trying to log in with those values, you'll get an invalid login attempt. Expected Results: The Autotyped values should exactly match what's in the data base. There should be no random conversion from upper-case to lower-case and logins should work. Additional Information: For my Fedora VM tests: - Linux Fedora 6.18.13-200.fc43.x86_64-bit - KDE Plasma Version: 6.6.1 - KDE Frameworks Version: 6.23.0 - Qt Version: 6.10.2 - Graphics Platform: Wayland - KeePassXC Flatpak 2.7.11 - Flatseal has Environment Variables SSH_AUTH_SOCK=$SSH_AUTH_SOCK and QT_QPA_PLATFORM=xcb I've reported this to both KeePassXC and Bazzite. In case it helps, here are the bug reports there: https://github.com/keepassxreboot/keepassxc/issues/13106 https://github.com/ublue-os/bazzite/issues/4269 If necessary (for comparing/contrasting), you can grab system details there.
I also tested this with the latest KDE Linux (based on Arch) distribution in a VM. The problem does NOT exist there.
I wonder how is it possible to use autotype on a Wayland session, since autotype does not work on Wayland and therefore is disabled on KeepassXC running in native Wayland mode. Perhaps is all about QT_QPA_PLATFORM=xcb
Yes. It's the QT_QPA_PLATFORM=xcb environment variable. Without it, the Autotype tab under Settings > General in KeePassXC doesn't even show up. With it, the tab appears, we can set the keystroke combination and it will somewhat work. It can't figure out what username/password entry to use (I guess Wayland won't let it find out what window it's in) so I have to filter the choices by typing the site name in the Autotype window. But, it's a whole lot better than having to manually do a CTRL-B/CTRL-V/CTRL-C/CTRL-V dance between KeePassXC and wherever I need the password. It was irritating, but at least it worked correctly. With these random upper-case to lower-case transformation, KeePassXC has become almost unusable now (which is why I gave it a High severity level).
All the quirks/glitches when trying using auto type on Wayland by using xcb are not / won't be addressed in the current Qt5 powered KeepassXC. The reason for having auto type disabled is because Qt5 support is poor. xcb is a workaround that should not be used. The migration to Qt6 is on progress, so soon the auto type will be enabled again https://github.com/keepassxreboot/keepassxc/pull/11651/