Created attachment 137330 [details] Screencap from Dolphin's "New Folder" dialog SUMMARY Ctrl+A and Backspace do not work as intended if you do this too fast, the cursor is simply moved to the beginning of the line. This is reproducible on both of my Fedora systems (33 and 34). STEPS TO REPRODUCE 1. Open Kate or press F10 in Dolphin to get a text box you can use 2. Put in a line of text 3. Press Ctrl+A and then immediately press Backspace _very_ quickly OBSERVED RESULT Selected text does not get deleted if you do this too fast. EXPECTED RESULT Selected text should be deleted. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 33/34 (available in About System) KDE Plasma Version: 5.20.5 and 5.21.3 KDE Frameworks Version: 5.79.0 and 5.80.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION I am unable to reproduce this with xdotool but it does work on both of my computers (both x11 and wayland). xdotool key --delay 0 ctrl+a key --delay 0 BackSpace
Created attachment 137331 [details] Screencap from Kate
Cannot reproduce. I don't think any KDE code could possibly be responsible for this. Do you have any input methods active?
I can reproduce this on a fresh Fedora 34 installation with no IME installed, and on my Fedora 33 installation which does have fcitx installed (but not activated).
Thanks. No idea what could possibly be causing this. Does it happen in Plasma text fields too? Or just in Dolphin and Kate?
Do the search fields in the clipboard and networkmanager widgets qualify as "plasma text fields"? If they do then yes I can reproduce it. On further inspection, it looks like Ctrl _might_ not have been physically released if I do this too fast, and other applications such as Firefox generally do not care and will clear the selection anyway. I'm having problems with KDE applications and plasma because they behave differently than everything else I'm accustomed to.
Yes, the clipboard and networkmanager widgets are part of Plasma and use a QtQuickControls2 text field, whereas Dolphin uses QWidgets and uses a QTextField (Or QLineEdit, can't remember which). Since it affects both, it sounds like this issue is deep in the input handling in Qt, far below any of the layers we can affect in KDE. I would recommend reporting it at https://bugreports.qt.io/ Thanks!