It seems like all Qt based applications are affected. For example, try the same in Dolphin in the location bar.

I can not reproduce that.

(In reply to Christoph Cullmann from comment #2)
> I can not reproduce that.

What's your Qt and KDE Frameworks version?

Kate: 25.12.2
KDE Frameworks: 6.23.0
Qt: Using 6.10.1 and built against 6.10.1
NixOS 26.05 (Yarara) (Wayland)
Build ABI: x86_64-little_endian-lp64
Kernel: linux 6.18.12

More or less just the same.
Perhaps I try it wrong.
I noticed (not with this) that sometimes in general chars are missing in the selection, but more from e.g. chromium to Kate

Created attachment 189969 [details]
recording to show the bug

I attached 2026-02-22 23-30-50.mp4

I do confirm for KWrite.

Fedora Linux 43

KDE Plasma Version:,6.6.0
KDE Frameworks Version:,6.23.0
Qt Version:,6.10.1
Kernel Version:,6.18.12-200.fc43.x86_64 (64-bit)
Graphics Platform:,Wayland

Additionally:

Keyboard Selection at Start of Line: If I position the cursor at the very beginning of a line and press Shift + Right Arrow, the cursor "jumps" immediately to the end of the first word, skipping the first character/word entirely and only selecting the text thereafter.

Incremental Selection Offset: If I place the cursor manually after the first character and press Shift + Right Arrow, the selection behaves correctly from that point forward. However, it is impossible to include the first character using incremental keyboard steps.

"Jump" Workaround: Using Shift + End (from the start of the line) works correctly.

Created attachment 190018 [details]
line edited upon selection

I confirm in kwrite / kate under Fedora 43.
Also, if the line starts with a special character (for example # or %) the line is edited (see the attached screencast).

The reported issues still exist, the latest updates from Fedora KDE spin did not help.

Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.1
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.18.13-200.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor
Memory: 64 GiB of RAM (62.7 GiB usable)
Graphics Processor: AMD Radeon RX 9070 XT
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7D52
System Version: 1.0

The same Kate/Kwrite version 25.12.2 works perfectly fine on latest Kubuntu 26.04 snapshot. So this has to do something with the Qt version or KDE Frameworks version or something else. 

Operating System: Kubuntu 26.04
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.23.0
Qt Version: 6.9.2
Kernel Version: 6.19.0-6-generic (64-bit)
Graphics Platform: Wayland

(In reply to gggeri91 from comment #11)
> The same Kate/Kwrite version 25.12.2 works perfectly fine on latest Kubuntu
> 26.04 snapshot. So this has to do something with the Qt version or KDE
> Frameworks version or something else. 
> 
> Operating System: Kubuntu 26.04
> KDE Plasma Version: 6.5.5
> KDE Frameworks Version: 6.23.0
> Qt Version: 6.9.2
> Kernel Version: 6.19.0-6-generic (64-bit)
> Graphics Platform: Wayland

Correction: I think it's the Qt version, since KDE Frameworks is the same here.

I can reproduce the behaviors described above - this doesn't seem like it could be a Kate-specific issue given it shows up broadly in Qt-based applications, but I'm not exactly sure where it's originating?

from my tests seems to be related to wayland in a way i don't know so QT_QPA_PLATFORM=xcb should workaround the issue on wayland

I can confirm this weird behavior on my system on Fedora 43.  Does not happen when selection is from right to left.  Does not happen when selection is from left to right as long as the starting point is not at the beginning of the line.  If selection is started as far left as the second letter and the mouse is dragged to the right, then the selection works fine.  The abnormal behavior only happens when the selection starts at the very beginning of the line.
Very distressing when working with scripts.  Sometimes several words will vanish when the mouse button is released and I'll need to do several undo's to get it back to the way it was, that is if I can remember how it was.  and if not I'll need to close the file discarding the changes and start over.  I've switched to using gedit temporarily for scripts, but I'd much prefer Kwrite if you could get this fixed.
It happens in the sticky note widget also.  Does not happen in Okular, nor LibreOffice, nor gedit.  Does not happen when selecting text in Konsole, or Xterm. Hope this helps.
Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.1
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: 8 × Intel® Core™ i7-3770K CPU @ 3.50GHz
Memory: 16 GiB of RAM (15.3 GiB usable)
Graphics Processor: Intel® HD Graphics 4000

Can't reproduce the issue on latest EndeavourOS, despite it also has Qt v6.10.2. So it is not Qt related.

Operating System: EndeavourOS
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.19.6-arch1-1 (64-bit)
Graphics Platform: Wayland

*** Bug 517201 has been marked as a duplicate of this bug. ***

I get different behaviour across two machines, both with fully updated Fedora 43 KDE edition.

On this setup, I CAN reproduce the issue:

Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.1
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: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz
Memory: 8 GiB of RAM (7.6 GiB usable)
Graphics Processor: Intel® UHD Graphics 620


On this setup, I CANNOT reproduce, everything works correctly in Kate and KWrite:

Operating System: Fedora Linux 43
KDE Plasma Version: 6.6.1
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 5700X 8-Core Processor
Memory: 32 GiB of RAM (31.3 GiB usable)
Graphics Processor: NVIDIA GeForce RTX 3060 Ti

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.

An AI explanation about QT_QPA_PLATFORM=xcb
========================================
"QT_QPA_PLATFORM=xcb is an environment variable setting used by Qt applications on Linux to force the use of the X11 (xcb) platform backend instead of others like Wayland or eglfs."

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: 8 × Intel® Core™ i7-9700K CPU @ 3.60GHz
Memory: 48 GiB of RAM (46.8 GiB usable)
Graphics Processor 1: NVIDIA GeForce RTX 2060
Graphics Processor 2: Intel® UHD Graphics 630

Since it seems like it is not a KDE issue, I started a discussion on fedoraproject.org: 
https://discussion.fedoraproject.org/t/selecting-text-in-any-qt-app-corrupts-the-content/182737

I'm also not able to reproduce on Solus with KWrite 25.12.3 but I *can* with KWrite built from git-master on Solus. I also observe that KWrite indicates the line was edited.
I can also reproduce with Dolphin built from git-master

System where I cannot reproduce
Operating System: Solus 4.8
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.18.13-330.current (64-bit)
Graphics Platform: Wayland

System where I can reproduce - main differences are Plasma and KF
Operating System: Solus 4.8
KDE Plasma Version: 6.6.80
KDE Frameworks Version: 6.25.0
Qt Version: 6.10.2
Kernel Version: 6.18.13-330.current (64-bit)
Graphics Platform: Wayland

Lets try to narrow it down to Qt (and the infrastructure underneath Qt). With the following little test we can proove it is not KDE.

1) Simple QApplication with QLineEdit control
Create "test1.cpp" with the following content:

#include <QApplication>
#include <QLineEdit>
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    QLineEdit edit;
    edit.setPlaceholderText("Type something...");
    edit.show();
    return app.exec();
}

Compile and run with:
g++ test1.cpp -o test1 $(pkg-config --cflags --libs Qt6Widgets) && ./test1

Observations:
- The bug is reproduced
- This little program does not use anything from KDE
- Therefore we can say the issue is not within KDE, but rather in Qt or the infrastructure underneath

Same can be observed with QInputDialog.

2) Simple QApplication with QInputDialog
Create "test2.cpp" with the following content:

#include <QApplication>
#include <QInputDialog>
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    bool ok;
    QString text = QInputDialog::getText(
        nullptr,
        "Qt Test",
        "Enter something:",
        QLineEdit::Normal,
        "",
        &ok
    );
    return 0;
}


Compile and run with:
g++ test2.cpp -o test2 $(pkg-config --cflags --libs Qt6Widgets) && ./test2

For what it's worth...there does seem to be some interaction happening with some KDE component, though - I set up a Fedora GNOME VM, installed KWrite and Plasma, and:

* Running KWrite in a GNOME session doesn't show the issue
* Rebooting and logging into a Plasma session does show the issue
* Logging into a GNOME session, logging out, then logging into a Plasma session fixes the issue in Plasma until the next reboot

Something in the interaction between some component that's loaded with Plasma, and the base Qt components, seems to trigger the issue - and something about starting up the GNOME session components temporarily fixes it?

Okay, I'm not a dev, just a user.  But I've found something that might lead someone more knowledgable than I am in the right direction.  Apparently the on screen keyboard  or the system tray is involved somehow.  I was playing around with the system tray and trying different things.  Try this:
Got to system tray and make the on screen control always visible so you can change it back and forth.  Click to turn off the on screen keyboard.  Try a text selection.  It works normally on my system.  Click tray icon to turn on the on screen keyboard.  Text selection still works ok.  Now right click on the on screen keyboard icon and click to configure virtual keyboards and system settings shows up. Click to change the keyboard to a different one, then click it back to where it was.  No need to click apply.  Close system settings.  Now try a text selection, and the abnormal behavior shows up.  Now click the tray keyboard icon to turn off the on screen keyboard.  The abnormal behavior goes away, and text selection is normal again.
I know not what's going on with QT or Wayland.  Just tossing this out in case it might help.

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: 8 × Intel® Core™ i7-3770K CPU @ 3.50GHz
Memory: 16 GiB of RAM (15.3 GiB usable)
Graphics Processor: Intel® HD Graphics 4000

(In reply to Tom from comment #25)
> Apparently the
> on screen keyboard  or the system tray is involved somehow.  I was playing
> around with the system tray and trying different things.  Try this:
> Got to system tray and make the on screen control always visible so you can
> change it back and forth.  Click to turn off the on screen keyboard.  Try a
> text selection.

I don't use the on-screen keyboard, but I saw in my system settings that the "Virtual Keyboard" mode was set to "Plasma Keyboard". (I don't think I had intentionally set this, it seems to be a recent Fedora change.)

I changed it back to "None", and the selection problem disappeared.

Something else is weird in the "Virtual Keyboard" settings screen though. When I return to it, 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 the problem recur though, by changing the setting to “iBus Wayland” and then from that to “Plasma Keyboard”.)

I confirm that switching the virtual keyboard setting to anything else than Plasma Keyboard solves the problem.

For the non-Fedora users who didn't experience this problem, it would be interesting to know:

1) In your distro, is the "Keyboard >> Virtual Keyboard" setting in the System Settings app defaulted to "Plasma Keyboard"?
2) If not, can you reproduce this problem when you change that setting to "Plasma Keyboard"?

Yes the virtual keyboard in system settings did revert to "plasma keyboard" on mine also.  I hadn't noticed that before.  I don't use the virtual keyboard so I just ignored that setting when I set up the system.  I read somewhere that it interacted with the touchscreen setting.  I wanted to see if it was involved. Since my system doesn't have a touchscreen, that setting doesn't show up unless I search for it.  There's a setting in Workspace > General Behavior.  It was set at "Automatically enable as needed".  I changed that to "disabled".  But that doesn't seem to make any difference with the keyboard issue.
I just upgraded to the latest from the Fedora repo.  New kernel and some KDE programs.  Seems one thing has been fixed.  The system setting no longer reverts to "Plasma Keyboard".  I can leave it on 
Maliit and it stays there.  I can click the sys tray icon to enable or disable the virtual keyboard and the text selection problem does not recur.  Changing the keyboard back to Plasma in system settings does not make the problem recur as long as the virtual keyboard is disabled in the system tray.  But clicking that icon to enable the virtual keyboard with the system setting set to "Plasma Keyboard" makes the problem recur.

New system specs after upgrade. Seems the only difference is the new kernel.

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.19.6-200.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-3770K CPU @ 3.50GHz
Memory: 16 GiB of RAM (15.3 GiB usable)
Graphics Processor: Intel® HD Graphics 4000

Disabling Plasma Keyboard fixes for me on Fedora Linux 43 as well - however, I cannot reproduce on KDE Linux even with with Plasma Keyboard enabled.

I don't know if any of these upstream Qt bugs are potentially relevant in some way, but maybe they might be a lead for someone more familiar with QtVirtualKeyboard?

https://qt-project.atlassian.net/browse/QTBUG-128152 - Manage mouse event delivery to popups and qvirtualkeyboard
https://qt-project.atlassian.net/browse/QTBUG-138706 - [Wayland] Application freeze when mouse is doing UI-blocking operations
https://qt-project.atlassian.net/browse/QTBUG-137393 - No drag cursor when dragging under wayland 
https://qt-project.atlassian.net/browse/QTBUG-141389 - a11y: QLineEdit reports space as a word when queried via a11y API

So far the key factors seem to be:
- Only occurs in native Wayland software - doesn't occur in an X11 desktop session, or when running an application using XWayland
- Only occurs if Plasma Keyboard is loaded - but that alone must not be enough, since the issue didn't appear in KDE Linux?

I was able to reproduce this bug using the latest KDE neon Unstable Edition live ISO (20260308-1147). Here's how:

1. Download the latest KDE neon Unstable Edition ISO (currently "neon-unstable-20260308-1147.iso"): https://neon.kde.org/download
2. Boot from the downloaded ISO file.
3. Once you are at the desktop, open Konsole and run `sudo apt update` and then `sudo apt install plasma-keyboard`.
4. Go to System Settings → Keyboard → Virtual Keyboard, then select "Plasma Keyboard".

Now you can fire up Kate and reproduce the bug described in the original report.

I can reproduce something similar (and worse), also on Fedora 43:
The first word is not just skipped, there's also N characters after the first word that are DELETED, and this deletion is impossible (or not always possible) to undo. (for now I saw 4 ≥ N ≥ 2, I guess it may depend on the length of the first word)
If I try to undo, it just deletes the first word as well.
If I try to undo more steps, the results are not really predictable (or I just couldn't make sense of it yet).

Also has anyone been able to reproduce it on Arch btw? IIRC it has a way to do an equivalent of git bisect for the whole set of packages, so in that case it should be possible to "triangulate" the issue wherever it might be

This is also reproduceable with the initial release (0.1.0) of plasma-keyboard.

Operating System: Manjaro Linux 
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.12.73-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-6700 CPU @ 3.40GHz
Memory: 24 Gio of RAM (23.2 Gio usable)
Graphics Processor: Intel® HD Graphics 530

*** Bug 518055 has been marked as a duplicate of this bug. ***

Migrating my steps to reproduce from Bug 518055.

STEPS TO REPRODUCE
1. Open Kate, Ctrl+N to get a new blank document.
2. Enter exactly the following text (without the backticks)
```
This is some introductory text: 


> this is a quote

This is not a quote
```
3. Move the mouse pointer to the left of the >, then click and drag to the right, as if to select the quoted text.

OBSERVED RESULT
The > character disappears! Undoing with Ctrl+Z does not bring back the deleted character; in fact it makes the situation worse by removing the word "this".


I'm upgrading this to VHI critical since it can cause unrecoverable data loss.

I have narrowed it down to this commit https://invent.kde.org/plasma/plasma-keyboard/-/commit/1c086c91667f13eae65d50ae4d913314deb6acd4. At least I cannot reproduce with Kate on the commit before, but older checkouts (also the one before this commit) break terminal, I cannot press enter or use arrows to browse in the history.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-keyboard/-/merge_requests/103

Git commit 74f81e65ff25e86d20c1e71b31ee94e3cb2e1adf by Aleix Pol Gonzalez, on behalf of Devin Lin.
Committed on 02/04/2026 at 16:47.
Pushed by devinlin into branch 'master'.

inputlisteneritem: Don't let Qt VKBD communicate to KWin when not
visible

This is a workaround to prevent the possibility of events from Qt VirtualKeyboard's input engine to be communicated
to KWin. During every text input session, we are still relaying events
to Qt VirtualKeyboard. Qt VKBD however assumes that it's the sole owner
of the text field and behaves in inexplicable ways when things change
(ex. mouse text cursor selection) to implement its own text prediction.

Workaround this for now by disabling communciation with KWin from Qt
VKBD when the input panel isn't shown. This means that BUG: 516511 will
still exist when the virtual keyboard panel is shown.

M  +12   -2    src/inputlisteneritem.cpp

https://invent.kde.org/plasma/plasma-keyboard/-/commit/74f81e65ff25e86d20c1e71b31ee94e3cb2e1adf

Git commit 78fe5acab545b4b558284d1731e9efda91f52613 by Devin Lin.
Committed on 02/04/2026 at 17:12.
Pushed by devinlin into branch 'Plasma/6.6'.

inputlisteneritem: Don't let Qt VKBD communicate to KWin when not visible

This is a workaround to prevent the possibility of events from Qt VirtualKeyboard's input engine to be communicated
to KWin. During every text input session, we are still relaying events
to Qt VirtualKeyboard. Qt VKBD however assumes that it's the sole owner
of the text field and behaves in inexplicable ways when things change
(ex. mouse text cursor selection) to implement its own text prediction.

Workaround this for now by disabling communciation with KWin from Qt
VKBD when the input panel isn't shown. This means that BUG: 516511 will
still exist when the virtual keyboard panel is shown.

M  +12   -2    src/inputlisteneritem.cpp

https://invent.kde.org/plasma/plasma-keyboard/-/commit/78fe5acab545b4b558284d1731e9efda91f52613

*** Bug 518352 has been marked as a duplicate of this bug. ***

It does not sound like this bug or problem has been resolved.  Although there is a work-around, closing this thread does not seem like the correct response.  

(In reply to Devin Lin from comment #40)
> Git commit 78fe5acab545b4b558284d1731e9efda91f52613 by Devin Lin.
> Committed on 02/04/2026 at 17:12.
> Pushed by devinlin into branch 'Plasma/6.6'.
> 
> inputlisteneritem: Don't let Qt VKBD communicate to KWin when not visible
> 
> This is a workaround to prevent the possibility of events from Qt
> VirtualKeyboard's input engine to be communicated
> to KWin. During every text input session, we are still relaying events
> to Qt VirtualKeyboard. Qt VKBD however assumes that it's the sole owner
> of the text field and behaves in inexplicable ways when things change
> (ex. mouse text cursor selection) to implement its own text prediction.
> 
> Workaround this for now by disabling communciation with KWin from Qt
> VKBD when the input panel isn't shown. This means that BUG: 516511 will
> still exist when the virtual keyboard panel is shown.
> 
> M  +12   -2    src/inputlisteneritem.cpp
> 
> https://invent.kde.org/plasma/plasma-keyboard/-/commit/
> 78fe5acab545b4b558284d1731e9efda91f52613

(In reply to Cameron Tanner from comment #42)
> It does not sound like this bug or problem has been resolved.  Although
> there is a work-around, closing this thread does not seem like the correct
> response.  
> 
> (In reply to Devin Lin from comment #40)
> > Git commit 78fe5acab545b4b558284d1731e9efda91f52613 by Devin Lin.
> > Committed on 02/04/2026 at 17:12.
> > Pushed by devinlin into branch 'Plasma/6.6'.
> > 
> > inputlisteneritem: Don't let Qt VKBD communicate to KWin when not visible
> > 
> > This is a workaround to prevent the possibility of events from Qt
> > VirtualKeyboard's input engine to be communicated
> > to KWin. During every text input session, we are still relaying events
> > to Qt VirtualKeyboard. Qt VKBD however assumes that it's the sole owner
> > of the text field and behaves in inexplicable ways when things change
> > (ex. mouse text cursor selection) to implement its own text prediction.
> > 
> > Workaround this for now by disabling communciation with KWin from Qt
> > VKBD when the input panel isn't shown. This means that BUG: 516511 will
> > still exist when the virtual keyboard panel is shown.
> > 
> > M  +12   -2    src/inputlisteneritem.cpp
> > 
> > https://invent.kde.org/plasma/plasma-keyboard/-/commit/
> > 78fe5acab545b4b558284d1731e9efda91f52613

I totally agree.  A workaround is not a fix and this bug should NOT be marked as resolved.  There's too much kicking the can down the road, and it very rarely does anybody any good.  This is why many people do not trust KDE software, especially for anything security-related.

Git commit 3020ba6fa14832663c579dad0b4df747cd1ea259 by Devin Lin.
Committed on 07/04/2026 at 04:12.
Pushed by devinlin into branch 'master'.

inputlisteneritem: Always disable predictive text

The vast majority of text fields (most text-input-v2, all text-input-v3)
don't actually have predictive text enabled. The ones that do experience
havoc when dealing with a mouse selecting text, and unexpected behavior
with the Qt VirtualKeyboard hunspell plugin.

From my digging, this is my hypothesis:

The Qt VKBD hunspell plugin deletes and reinserts the current word on every
cursor event. It seems to expect the cursor position to remain the
same after, but in plasma-keyboard we have no way of knowing that the
hunspell plugin intended to do that, so the state update causes the
cursor position to move to the end of the word. I don't really know
think we can really address this without making our own text autocompletion
plugin.

M  +5    -3    src/inputlisteneritem.cpp

https://invent.kde.org/plasma/plasma-keyboard/-/commit/3020ba6fa14832663c579dad0b4df747cd1ea259

Git commit 59b27fcc2680f88b40b8cbfe6f45f11392fbc5d5 by Devin Lin.
Committed on 07/04/2026 at 04:17.
Pushed by devinlin into branch 'Plasma/6.6'.

inputlisteneritem: Always disable predictive text

The vast majority of text fields (most text-input-v2, all text-input-v3)
don't actually have predictive text enabled. The ones that do experience
havoc when dealing with a mouse selecting text, and unexpected behavior
with the Qt VirtualKeyboard hunspell plugin.

From my digging, this is my hypothesis:

The Qt VKBD hunspell plugin deletes and reinserts the current word on every
cursor event. It seems to expect the cursor position to remain the
same after, but in plasma-keyboard we have no way of knowing that the
hunspell plugin intended to do that, so the state update causes the
cursor position to move to the end of the word. I don't really know
think we can really address this without making our own text autocompletion
plugin.

M  +6    -4    src/inputlisteneritem.cpp

https://invent.kde.org/plasma/plasma-keyboard/-/commit/59b27fcc2680f88b40b8cbfe6f45f11392fbc5d5

*** Bug 518694 has been marked as a duplicate of this bug. ***

Hello. I see that this has been fixed. I am also on fedora, plasma 6.6.3 - when will this ship (which version)? Thanks!

*** Bug 518791 has been marked as a duplicate of this bug. ***