SUMMARY This behaviour happens randomly but often when I read emails. Unfortunately I can not tell how to reproduce. All I can say that this happens every couple of days. When I point the mouse to the black square the cursor turns from "default" to "resize" (see screenshot). SOFTWARE/OS VERSIONS Operating System: Fedora 33 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.7-200.fc33.x86_64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4770T CPU @ 2.50GHz Memory: 7.2 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600
Created attachment 135056 [details] Black square 1
Created attachment 135057 [details] Black square 2
I get it too on Debian Bullseye. I'd include a screenshot, but it's pretty much the same.
The same problem appears to exist in qBittorrent <https://github.com/qbittorrent/qBittorrent/issues/13368> In both cases, it seems to be over a QSplitter.
I don't see it anymore since months.
Can you see if "killall xembedsniproxy" fixes it?
If it occurs in multiple programs it is likely a style bug (presumably breeze). If you're up to it, you could try running kmail as "kmail -style fusion" to try a different theme (Qt has a "Fusion" theme built-in) and see if the black square still comes up at random intervals. Note that KMail will look a bit different if you run it this way since the style is different.
Marking as needs info based on my comment. If that does "fix" it please move to xembedsniproxy in plasmashell and reopen.
Inspecting with GammaRay shows that this is the Breeze SplitterProxy. It has visible=true, which means that it for some reason didn't hide properly. Using gdb, it shows that _splitter is null, so the underlying handle was deleted before the SplitterProxy was cleared. clearSplitter() has "if( !_splitter ) return;", so once it's in that state it never hides itself again. I'm wondering which handle it is which got deleted, but this should be relatively simple to fix in any case by also clearing if _splitter is null. It might need a new variable to track whether the proxy is currently active, but isVisible() might suffice. I can make a MR, but to be able to test it I'd have to know what SplitterProxy is actually for, it's not obvious... The issue is also not easy to reproduce.
I found a way to reproduce it: 1. Start dragging on the vertical (|) splitter below the intersection (|-) 2. Drag upwards until the cursor is on the intersection, then drag a bit to the right 3. Release the mouse button to spawn a square
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/95
Git commit d201a1f187243da677f8fa6e94325c41c3b9007c by Fabian Vogt. Committed on 09/04/2021 at 09:33. Pushed by fvogt into branch 'master'. Fix SplitterProxy not clearing when above another QSplitterHandle When two SplitterHandles are next to each other, like at the intersection of a horizontal and vertical splitter (|-), then it's possible that hiding the proxy of one of those handles causes the other handle to gain focus immediately, which activates the SplitterProxy again. Before this patch, it would then continue clearing after reenabling itself, leading to an inconsistent state. M +6 -6 kstyle/breezesplitterproxy.cpp https://invent.kde.org/plasma/breeze/commit/d201a1f187243da677f8fa6e94325c41c3b9007c
Git commit cc613558bae7c809e36951da89db3c7cc1a5a58e by Fabian Vogt. Committed on 09/04/2021 at 11:16. Pushed by fvogt into branch 'Plasma/5.18'. Fix SplitterProxy not clearing when above another QSplitterHandle When two SplitterHandles are next to each other, like at the intersection of a horizontal and vertical splitter (|-), then it's possible that hiding the proxy of one of those handles causes the other handle to gain focus immediately, which activates the SplitterProxy again. Before this patch, it would then continue clearing after reenabling itself, leading to an inconsistent state. (cherry picked from commit d201a1f187243da677f8fa6e94325c41c3b9007c) M +6 -6 kstyle/breezesplitterproxy.cpp https://invent.kde.org/plasma/breeze/commit/cc613558bae7c809e36951da89db3c7cc1a5a58e
Git commit 6c3a46e0f1abb697fb0900f21196cafcbd8ee37c by Fabian Vogt. Committed on 09/04/2021 at 11:16. Pushed by fvogt into branch 'Plasma/5.21'. Fix SplitterProxy not clearing when above another QSplitterHandle When two SplitterHandles are next to each other, like at the intersection of a horizontal and vertical splitter (|-), then it's possible that hiding the proxy of one of those handles causes the other handle to gain focus immediately, which activates the SplitterProxy again. Before this patch, it would then continue clearing after reenabling itself, leading to an inconsistent state. (cherry picked from commit d201a1f187243da677f8fa6e94325c41c3b9007c) M +6 -6 kstyle/breezesplitterproxy.cpp https://invent.kde.org/plasma/breeze/commit/6c3a46e0f1abb697fb0900f21196cafcbd8ee37c