After kwin crashes and is restarted there will be two squares as shown in the linked screenshot, one in the panel over the tray and one in the top left corner of the screen. The squares blocks you from clicking whatever they cover, but sometimes clicking the top left square acts as if you click whatever is behind the square in the system tray. The square are black as in the screenshot when compositing is disabled and invisible when compositing is enabled. Restarting Kwin or Plasma does not fix it. Reproducible: Always Steps to Reproduce: 1. Kill kwin 2. Start kwin_x11 Actual Results: Weird squares as mentioned in details. Expected Results: No squares Nvidia Geforce 780 with proprietary driver 352.63. GLX+openGL 3.1 compositing
Looks quite like systray icons to me? Maybe from the fdo systray plugin in plasmashell (resp. the previously hosted clients which are now orphaned)? At least it's not in kwin and apparently not in plasmashell (directly) either.
Seems to be related to the "MinimizeToTray revived" extension in Thunderbird. It only happens if Thunderbird is running, and the Thunderbird icon disappears when you kill the "squares" with ctrl+alt+esc.
can you check whether an application called "xembedsniproxy" is running?
Yes, "xembedsniproxy" is running, and seems to be the process the "squares" belongs to, as using ctrl+alt+esc on the "squares" kills "xembedsniproxy". Restarting it fixes the issue.
clicking the area in the systray where the proxied application is shown causes the proxy windows to be "re-absorbed". that's of course quite a challenge, as these windows are usually placed somewhat exactly at this place (they are always a few pixels off, and sometimes there is almost no overlap - probably related to the preceding kwin crash and the resulting re-layouting).
*** Bug 375686 has been marked as a duplicate of this bug. ***
Created attachment 104571 [details] Rendererror on my system I get the same error, when i disable compositing (i need to do this after resume from software suspend, because kwin seems to have quite a few problems then until it is restarted). Black squares: KMenu, pidgin, gajim. Possibly this has to do with legacy/new style trayicons, which ones are black?
debian stretch, plasma-workspace 5.8.4
Using Debian/unstable, that bug still occurs. Apparently BasKet 2.10-beta and KeePassX 2.0.3 need xembedsniproxy and cause the black squares.
I can confirm the black squares after kwin to be restarted if compositing is disabled. Operating System: Arch Linux KDE Plasma Version: 5.15.3 KDE Frameworks Version: 5.56.0 Qt Version: 5.13.0
*** Bug 409396 has been marked as a duplicate of this bug. ***
Based on Patrick's information (Thanks!), this issue is 100% reproducible for me with the following steps to reproduce. 1. Open the Riot app, which display a system tray icon 2. suspend compositing with Alt+Shift+F12 3. kwin_x11 --replace The black or invisible square that accepts mouse input will then appear in the top-left corner of the screen.
This is exactly what happens: For each tray icon XEmbedSNIProxy is creating container window 32x32 in size. It is black with opaque set to 0 (fully transparent when compositor is enabled). All of these container windows are stacked below all windows, so normally you can't see it. On creation all conteiner windows are created in top-left corner. When user clicks on tray icon, container window is moved to click location (to handle events correctly). That's why you can see/detect black (or transparent) windows in top-left or covering the icon. After each click container windows is stacked below again - that's why it usually disappears after click. On KWin restart all windows are shuffled, usually KWin is able to restore ordering correctly, but for some reason not it this case. As a result black/transparent container windows are stacked above all other windows and panels. To solve that, on kwin restart, we can iterate over all known container windows and stack them below again. It should be possible to detect KWin restart from inside XEmbedSNIProxy
thanks for looking A quick hack (which is all xembedsniproxy is anyway!) would be to make a QDBusServiceWatcher on org.kde.KWin A better version would probably be to either monitor the property _NET_SUPPORTING_WM_CHECK on the root window Or to watch the stacking order and reposition ourselves if needed Or we find what's going on and fix kwin
*** Bug 400855 has been marked as a duplicate of this bug. ***
Git commit 02bbef3b506aa4c605cee88bd39a6d88dea63f34 by Konrad Materka. Committed on 29/11/2019 at 08:39. Pushed by kmaterka into branch 'Plasma/5.17'. [XembedSNIProxy] Send all container windows to background on KWin restart Summary: For each tray icon XEmbedSNIProxy is creating container window 32x32 in size. It is black with opaque set to 0 (fully transparent when compositor is enabled). All of these container windows are stacked below all windows, so normally you can't see them. On creation all container windows are created in top-left corner. When user clicks on the tray icon, container window is moved to the click location (to handle events correctly). On KWin restart all windows are shuffled, usually KWin is able to restore ordering correctly, but for some reason not it this case. As a result black/transparent container windows are stacked above all other windows and panels. To solve that, on KWin restart, XembedSNIProxy needs to iterate over all known container windows and stack them below again. Test Plan: 1. [Optional] Disable compositor - with disable container window is black and easier to spot 2. Run any application with XEmbed system tray icon, do not click on the icon 3. Restart KWin a) Before: black/transparent rectangle in the top-left corner, reacts to mouse click b) After: no rectangle, mouse clicks work as expected Reviewers: #plasma_workspaces, #plasma, davidedmundson Reviewed By: #plasma_workspaces, #plasma, davidedmundson Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D25603 M +13 -1 xembed-sni-proxy/fdoselectionmanager.cpp M +10 -6 xembed-sni-proxy/sniproxy.cpp M +1 -0 xembed-sni-proxy/sniproxy.h https://commits.kde.org/plasma-workspace/02bbef3b506aa4c605cee88bd39a6d88dea63f34
it's still happening on Arch Linux after update to Plasma 5.17.4. open an app with legacy tray icon restart kwin with "kwin_x11 --replace" disable compositing by pressing alt+shift+f12 Result: black square in the upper left corner.
Yes, I just tested and it is still not fixed. To be precise: there is a race condition, if KWin restart is quick (less than 100 milliseconds) it is working correctly. There is no need to disable compositor, with compositor enabled square is transparent but still covers other windows/panels. Note for testers: While testing, it is important *not* to click on the tray icon before KWin restart. If you click, black/invisible square will appear, but at the location of the click. Still, not correct, but more difficult to spot. It is very tricky to fix this correctly, but I will continue working on this.
Another attempt: https://phabricator.kde.org/D26395
Git commit 69786a1ff94718daf4de2d814037e70df079ec97 by Konrad Materka. Committed on 08/01/2020 at 16:06. Pushed by kmaterka into branch 'master'. [XembedSNIProxy] Hide container window when something shows it Summary: For each tray icon XEmbedSNIProxy is creating container window 32x32 in size. It is black with opaque set to 0 (fully transparent when compositor is enabled). All of these container windows are stacked below all windows, so normally you can't see them. On creation all container windows are created in top-left corner. When user clicks on the tray icon, container window is moved to the click location (to handle events correctly). On KWin restart all windows are shuffled, usually KWin is able to restore ordering correctly, but for some reason not it this case. As a result black/transparent container windows are stacked above all other windows and panels. To solve that, when container window is visible, XembedSNIProxy needs hide it again by stacking the container window below again. FIXED-IN: 5.18.0 Test Plan: 1. Run any application with XEmbed system tray icon, do not click on the icon 2. Restart KWin 3. [Optional] Disable compositor - with disable container window is black and easier to spot 4. Expected: a) before fix: black/transparent rectangle in the top-left corner, reacts to mouse click b) after fix: no rectangle, mouse clicks work as expected. Reviewers: #plasma_workspaces, #plasma, davidedmundson Reviewed By: #plasma_workspaces, #plasma, davidedmundson Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D26395 M +10 -15 xembed-sni-proxy/fdoselectionmanager.cpp M +23 -9 xembed-sni-proxy/sniproxy.cpp M +4 -2 xembed-sni-proxy/sniproxy.h https://commits.kde.org/plasma-workspace/69786a1ff94718daf4de2d814037e70df079ec97
The bug is not resolved for me with plasma 5.17.5 / KF 5.70 / Qt 5.14.2. It happens for me when I have pidgin in autostart and probably pidgin starts before kwin/plasma is started.
The bug was fixed in 5.18.0. :)
Somebody just suggested that fix from this bug caused bug 425271 (high CPU usage and very fast .xsession-errors growth whenever - in multi-monitor setup - two monitors of different sizes are not configured to be perfectly top-aligned).
I have this bug with kde-plasma/plasma-workspace-6.1.5-r3 on Gentoo. kwin_x11 (rare) crash causes this black square on the left top corner, and restarting xembedsniproxy (as suggested here) removes it.