Bug 432744

Summary: xembedsniproxy produces a square in the top-left corner that may either eat clicks or be filled in with black color
Product: [Plasma] plasmashell Reporter: Nate Graham <nate>
Component: XembedSNIProxyAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: darinsmiller, kde, materka, tneo, vlad.zahorodnii
Priority: VHI Keywords: regression
Version: master   
Target Milestone: 1.0   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=433079
https://bugs.kde.org/show_bug.cgi?id=436104
https://bugs.kde.org/show_bug.cgi?id=357443
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Black square in the corner

Description Nate Graham 2021-02-10 16:22:45 UTC
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.
Comment 1 Nate Graham 2021-02-10 16:46:54 UTC
This issue is reproducible on Wayland too.
Comment 2 Nate Graham 2021-02-10 18:34:06 UTC
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.
Comment 3 David Edmundson 2021-02-11 10:23:58 UTC
If you run killall xembedsniproxy does it go away?
Comment 4 Nate Graham 2021-02-11 14:39:30 UTC
Yes!
Comment 5 Nate Graham 2021-02-12 14:04:44 UTC
Ah, this seems to be Systemd-startup-related. I didn't start seeing it until I enabled Systemd startup.
Comment 6 Konrad Materka 2021-02-15 16:37:54 UTC
Ah, here we go again... I tried to fix this in Bug 357443
Comment 7 Nate Graham 2021-02-17 23:06:46 UTC
*** Bug 433079 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2021-02-17 23:07:35 UTC
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.
Comment 9 Darin Miller 2021-02-22 21:53:35 UTC
*** Bug 433396 has been marked as a duplicate of this bug. ***
Comment 10 Konrad Materka 2021-03-01 21:11:42 UTC
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.
Comment 11 David Edmundson 2021-03-01 21:21:14 UTC
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
Comment 12 Konrad Materka 2021-03-02 16:52:42 UTC
@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.
Comment 13 Konrad Materka 2021-03-02 22:41:30 UTC
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.
Comment 14 Bug Janitor Service 2021-03-03 07:19:45 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/744
Comment 15 Vlad Zahorodnii 2021-03-03 07:20:16 UTC
@Konrad can you please test ^^^ ?
Comment 16 Konrad Materka 2021-03-03 16:43:29 UTC
(In reply to Vlad Zahorodnii from comment #15)
> @Konrad can you please test ^^^ ?

Your patch fixed this issue.
Comment 17 Aleix Pol 2021-03-04 06:38:37 UTC
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