Selecting text in any Qt app corrupts the content

Ask Fedora
1

Selecting text in any Qt app corrupts the content. This happens only on Fedora atm.

STEPS TO REPRODUCE

  1. Create a new text file “test.txt” with a few lines of text.
  2. Open “test.txt” with Kate or Kwrite application
  3. Move your mouse cursor to the beginning of a line
  4. Hold down the left mouse button to start selection
  5. Drag the mouse while still holding the left mouse button to the right to select the text in the line
  6. Release the left mouse button at the end of the line.

OBSERVED RESULT
The first word of the line is corrupted when selecting. You will notice the “Undo” button activating when it happened as a symptom.

EXPECTED RESULT
Selecting text with mouse works as expected even when the selection starts from the very first character in the line.

  • I can say all Qt apps are affected, but it is not a Qt issue, because the same Qt version works fine on EndeavourOS
  • Seems like it is not a KDE related issue
  • So it might be a weird combination in Fedora, I am just guessing at this point. But it’s not KDE, and not Qt as far as I can tell, more likely it is something with Wayland

Example with Kate (it is just one of the affected apps!):
2026-03-08 09-27-01

Text replacement
"Plasma Keyboard" can cause various input issues on KDE Plasma 6.6 systems
2

I can’t reproduce this on my desktop with a mouse, but I can on my laptop (both with touchpad and with mouse). Both are Fedora 43 KDE with all updates applied.

I’ll experiment a bit more and see if I can get any more clues.

3

OK, a couple more observations:

  1. I only get the specific behaviour in your video when the line starts with some kind of “bracket” character (( or [ or < all do it, but normal alphabetical characters don’t).
  2. I can reproduce the behaviour purely using the keyboard. i.e. if I have a text file identical to yours, then I put the cursor at the top left, hold down Shift and hit the right arrow a couple of times – no mouse involved – then I also see the < disappear.
  3. Sometimes when clicking and dragging, I see a string from the clipboard be pasted in. My first thought was “middle-click paste gone haywire”. But disabling middle-click paste doesn’t make any difference.

Are these the same as you see?

(1) and (2) make me wonder if it’s related to Kate and KWrite trying to do “syntax-aware” things with brackets. But that doesn’t explain why my two different machines with the same software versions behave differently.

4

I see odd selection behaviour on the first word as well, but no corruption.

What I see is that trying to select the first few words of a line skips the first word.

I used the text “The fish flys at midnight.”.

I used both kate and kwrite to test this.

1 Like
5

What if you use:

<The fish flys at midnight.>

I found that to get the “corruption”, I needed the first character to be a bracket of some description.

6

I see that the “<” is removed as I select the text.

So they seem to have more then one selection related problem.

I think progressing these issues has to be done with reports directly to the KDE folks.
Starting on https://discuss.kde.org/ and filing bug reports if you ask for them in the KDE bug tracker.

1 Like
7

The only catch I wonder about is that in the existing KDE bug report for this, everyone reporting the issue is using Fedora, and folks running Arch and Ubuntu-based systems can’t reproduce it.

Is it possible that something related to Qt versions present when building vs. when running is at play? I seem to remember some funky issues occurring in the past when Qt updated and dependent programs weren’t rebuilt with the new version - although this issue seemed to appear before the Qt 6.10.2 update got rolled out?

1 Like
8

I cannot reproduce this.

I tried

  • touchpad or keyboard (shift+right) selection
  • plain lorem ipsum
  • <lorem> ipsum
  • Kwrite and Kate
  • from the beginning of a line and from the beginning after a soft-wrapped line.

Edit: sorry, forgot to include this:

Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.18.16-200.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics
Memory: 32 GiB of RAM (30.0 GiB usable)
Graphics Processor: AMD Radeon 780M Graphics
Manufacturer: LENOVO
Product Name: 21K3CTO1WW
System Version: ThinkPad T14 Gen 4
9

Interesting, thanks for providing that! For what it’s worth, I can reproduce on my device with the setup below:

Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.18.16-200.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7800X3D 8-Core Processor
Memory: 32 GiB of RAM (30.4 GiB usable)
Graphics Processor 1: NVIDIA GeForce RTX 4070 SUPER
Graphics Processor 2: AMD Ryzen 7 7800X3D 8-Core Processor
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7D78
System Version: 1.0

But I can’t reproduce on the same hardware, booted into KDE Linux.

10

Your observations match mine.

This affects all Qt based apps, Kate and Kwrite are just the easiest to demonstrate with.
If you click into the address bar in Dolphin, and you try to select the path from left to right, you will see the first forward slash character vanish.
Similar issue can be observed with any Qt dialog like file/folder rename dialogs.

So based on the symptoms it has nothing to do with syntax highlight, see this other example with plain text where the selection skips the first word (note that the Undo button appears!):
test2

I did open this on KDE bugtracker, but so far it seems like it is not a KDE issue. Me and others have no idea where it’s coming from, but comment #19 touched on something!

If I set the environment variable QT_QPA_PLATFORM=xcb in a terminal window and start kwrite from there, the problem is gone, but just for the kwrite instance(s) started from that specific terminal window.

It is my guess that the weird selection problem and the corruption issue originates from the same root cause. In both cases some weird input is happening into the text editor control.

11

Neal @ngompa do you want a bug raised for KDE SIG folks to look at this?
Or is there a better place to look for help?

12

Please file a bug with rhbz and maybe Qt itself. This probably needs to be a blocker bug for F44 Final too.

1 Like
13

I’m not on Fedora 43, but I am running the same versions but w/X11 and I don’t have any issues. Select, grab and move works here.

kde-kate-test-selection-test-1

$ kcmshell6 kcm_about-distro --args dump
Operating System: Fedora Linux 42
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.18.16-100.fc42.x86_64 (64-bit)
Graphics Platform: X11
Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor
Memory: 128 GiB of RAM (125.0 GiB usable)
Graphics Processor: NVIDIA GeForce RTX 4060
14

A comment on the KDE bug ticket suggested that the on-screen keyboard was the culprit.

I don’t use on-screen keyboard but I noticed that the Virtual Keyboard mode in System Settings was set to “Plasma Keyboard”. (This is a recent addition I think - previously I’d only seen the “None”, “iBus Wayland” and “Malit” options.)

When I changed this to “None”, the problem disappeared.

Screenshot_20260312_132535
Screenshot_20260312_1325351019×436 44.1 KB

However, something weird is still going on with these settings. If I return to that settings screen, it no longer says “None” but has apparently reverted to “Plasma Keyboard”. But (even after rebooting) the original problem doesn’t recur.

I can make it recur by changing to “iBus Wayland” and then changing to “Plasma Keyboard”.

2 Likes
Arrow Keys on Keyboard not working for any text
"Plasma Keyboard" can cause various input issues on KDE Plasma 6.6 systems
15

This really works on Fedora. Changing the Virtual Keyboard to anything else than “Plasma Keyboard” did the trick.

But on EndeavourOS I could never reproduce this bug in the first place. With or without “Plasma Keyboard”. I’ve just retested this now.

1 Like
16

Interesting… I have no option / choice of “Virtual Keyboard” in my KDE Keyboard - System Settings… Only “Keyboard”, “On-Screen Keyboard” and “Shortcuts”….

Does that mean I’m missing out on the fun? :slight_smile:

17

For what it’s worth, this got submitted to rhbz as 2449945 – KDE editor (kwrite, kate...) corrupts text on selection

Wonder if it’s possibly related to some underlying cause for 2446417 – plasma-keyboard 6.6.2 crashes with SIGSEGV in HunspellInputMethod::reselect() when receiving surrounding_text update via Wayland input method protocol on Fedora 43 KDE Plasma Wayland session as well?

1 Like
18

KDE has upgraded the bug to Critical importance.

19

I also had the issue in KDE-43 and Kinoite 43 and have it in Kinoite 44 and in Kinoite 45.
My solution was:
In KDE-Settings - Keyboard - Virtual keyboard I selected none and rebooted.
But, after the reboot the same setting is placed back to Plasma keyboard.
The error is gone however, I can now select the whole line of text including the first characters, with and without special characters like brackets.

Turns out, the reboot is not necessary, just selecting None instead of Plasma keyboard for the Virtual keyboard setting does the trick.
After a reboot the settings returns to Plasma keyboard but the error is stil gone.