Created attachment 169340 [details] a showcase of the bug using dolphin SUMMARY Changing keyboard layout set to Capslock (as the only way to change layouts) puts cursor at the beginning of a row in text fields of some applications STEPS TO REPRODUCE 0. Change layout switching method to CapsLock 1. Type something in one layout (i.e. English) 2. Switching layout to another one (i.e. Russian) by pressing Capslock OBSERVED RESULT Layout changes but the text input cursor is put at the beginning of a row or a text field as if "Home" or "PageUp" key is pressed. If some text is selected, it de-selects. EXPECTED RESULT Cursor stays in place, only layout changes. SOFTWARE/OS VERSIONS Linux/KDE Plasma: archlinux 6.8.9-zen (64-bit) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION 1. Only happens in some applications: a) telegram-desktop pacman build but not AppImage (works as expected in AppImage); b) nheko AppImage but not pacman (works as expected in pacman build); c) dolphin when renaming file but not when creating new file (with a textbox dialog popup); so far, these applications are all I have noticed this behavior in. 2. Only happens with CapsLock: default switching method (Alt+Shift) works fine; tried some variations of *+CapsLock, they all work fine. Layout switching is the only option I have changed in advanced keyboard options. Disabling CapsLock doesn't do change this behavior. Having other layouts doesn't change this behavior. 3. Started happening since update to Plasma 6, never happened in Plasma 5. My installation is a fresh (did it on launch of Plasma 6 on arch in February) one but with some dot files migrated from Plasma 5. There were no other issues, but I'm willing to experiment if pointed towards any relevant config files. 4. Recorded a short clip in dolphin. Note that I only press CapsLock and some random letters on a keyboard.
Cannot reproduce with current git master and Qt 6.7.2. Can you still reproduce it with Plasma 6.1.4, Frameworks 6.4, Qt 6.7.2 or newer?
(In reply to Nate Graham from comment #1) > Cannot reproduce with current git master and Qt 6.7.2. Can you still > reproduce it with Plasma 6.1.4, Frameworks 6.4, Qt 6.7.2 or newer? 6.1.3 is the newest in arch repos, but there is no point in waiting for 6.1.4, because I just created a new user on that machine, and it doesn't have this problem. It seems that my home directory dotfiles are tainted from previous installation (which is weird because the error did not happen on Plasma 5.21). How can one go about debugging which file exactly is at fault? I do not intend do start absolutely fresh (there is a lot of configuration done), I probably will go with pinpointing it manually (mass renaming of directories in $HOME until the file is found), but is there an easier way to know what config files are used by plasma to control keyboard behavior?
That's a good question. I'm afraid there isn't a trick to it, you just move aside config files until you find the one at fault. You could do it binary-tree style by moving aside half of them at a time per pass.
(In reply to Nate Graham from comment #3) > That's a good question. I'm afraid there isn't a trick to it, you just move > aside config files until you find the one at fault. You could do it > binary-tree style by moving aside half of them at a time per pass. I narrowed it down and it only took an hour. In ~/.config/kdeglobals was a line in a block [Shortcuts] Begin= Looking through shortcut settings, "Begin" is assigned to "Ctrl+Home" by default, which I had remapped as one of Spectacle's shortcuts back in Plasma 5 so it was empty since then. Removing the line and re-logging fixed that weird behavior. What is strange is pressing Ctrl+Home didn't put cursor at the beginning of the line in i.e. Telegram, but that is besides the point. So exact steps to reproduce the bug are: 0. Have layout switch key as CapsLock. 1. Remove/unbind the shortcut for "System settings" -> "Input & Output" -> "Keyboard" -> "Shortcuts" -> "Navigation" -> "Begin" so that there is a line "Begin=" in kdeglobals config file. 2. Re-log. 3. Try to rename something in Dolphin while switching layout back and forth every few symbols, your cursor will be put in the beginning of the text field every time you press CapsLock. While the original issue is resolved for me, this "Begin=" certainly looks like an unintended behavior, and it might be worth looking into although it is very minor. === Found an extra mini bug where my "Begin" was unbound (by clicking the checkbox in System settings) then bound back again after re-logging (by clicking the checkbox again), it turned out like this in kdeglobals: [Shortcuts] Begin=; Ctrl+Home So the shortcut both had no keybind and default keybind. And the original bug with CapsLock was triggering. === Thanks a lot for helping me, Nate! Big fan of your blog and your work.
Wow, great investigation! Ok, so there are a few things we can improve here. #1 If you try to un-bind or reassign one of the standard shortcuts, we need to show a warning that this could have far-reaching consequences and you must know what you're doing before proceeding. > What is strange is pressing Ctrl+Home didn't put cursor at the beginning of the line in i.e. Telegram These settings only affects KDE apps; 3rd-party apps don't have to listen to them. #2 We can definitely make this clearer in the KCM. Can you open new bug reports for those?