Created attachment 135562 [details] Black square in the corner See attached screenshot. This thing appeared a few days ago. It doesn't eat clicks, and `xprop` ignores it, identifying instead the window below it. It survives restarting plasmashell, restarting KWin, and rebooting. Disabling compositing makes it disappear though.
This issue is reproducible on Wayland too.
Similar visually to the issue in Bug 357443, which was fixed. However this black square doesn't eat clicks and doesn't seem to be a window at all, but rather some kind of compositing anomaly.
If you run killall xembedsniproxy does it go away?
Yes!
Ah, this seems to be Systemd-startup-related. I didn't start seeing it until I enabled Systemd startup.
Ah, here we go again... I tried to fix this in Bug 357443
*** Bug 433079 has been marked as a duplicate of this bug. ***
From Bug 433079, it looks like this also kills the hotcorner's ability to trigger something there when an app that actually uses xembedsniproxy is active. Raising the priority.
*** Bug 433396 has been marked as a duplicate of this bug. ***
It is even worse than I expected, black square is not hiding even when I click on the icon in the system tray (but it just moves as expected). That's bad... The implementation is quite tricky here, I need to investigate further.
you both can reproduce it reliably? Can someone run with QT_LOGGING_RULES=kde.xembedsniproxy.debug=true and get some traces If you have any unusual kwin config changes, can you mention it
@David I'm using X and KDE compiled from sources. On 5.21 and X everything works fine, I will test Wayland later. Using version from git I have black window stacked above other. Nothing interesting in logs but one message: "Container window visible, stack below" It means that container window is "UNOBSCURED". This is fine, it can happen when KWin or xembedsniproxy is restarted. In such case xembedsniproxy will try again to stack container window below root windows (plasma desktop) but for whatever reason it is no longer working! I'll test combining components from 5.21 and git (especially KWin). @All I'm surprised that it is even working (poorly, but it is) on Wayland! I have Nvidia card so when I last worked on xembedsniproxy it was not possible to run Wayland on Nvidia card. Few words of explanation (for anyone not familiar with xembedsniproxy). XEmbed is an old protocol for system tray icons. The application can render a small window that is embedded in the system tray (hence the name). In the new SNI protocol we can't embed windows, we need to use image (+ other data like title). To do that xembedsniproxy does few things: * create fake container window and embed tray icon into it * set transparency to 100% (and color to black) * stack container window below all other windows so that it does not interfere * copy image of the exmbedded window as a SNI icon.
There two separate bugs: * xembedsniproxy does not work well on Wayland * black square on latest version from git. Second issue is caused by this commit in KWin: 9acf04e2b741a851ffef88b3eadb5402d659dde8 is the first bad commit commit 9acf04e2b741a851ffef88b3eadb5402d659dde8 Author: Vlad Zahorodnii <vlad.zahorodnii@kde.org> Date: Sat Feb 6 00:18:45 2021 +0200 Refactor Toplevel::opacity I will reopen one of the duplicates for problems on Wayland.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/744
@Konrad can you please test ^^^ ?
(In reply to Vlad Zahorodnii from comment #15) > @Konrad can you please test ^^^ ? Your patch fixed this issue.
Git commit d9ec48225702e4ce272f13ea84a28cff7acdac0d by Aleix Pol Gonzalez, on behalf of Vlad Zahorodnii. Committed on 03/03/2021 at 11:58. Pushed by vladz into branch 'master'. x11: Initialize opacity when starting to track Unmanaged This is a minor regression that was introduced with the refactoring of Toplevel::opacity(). Previously, neither X11Client nor Unmanaged had to explicitly initialize the opacity because it was queried from the net info object in Toplevel::opacity(). With the refactored version, X11-specific opacity code was removed from the Toplevel class. When starting to manage a window, the opacity must be explicitly initialized. M +1 -0 src/unmanaged.cpp https://invent.kde.org/plasma/kwin/commit/d9ec48225702e4ce272f13ea84a28cff7acdac0d