Bug 357443 - black/invisible squares on systray and top left of screen after kwin restarted
Summary: black/invisible squares on systray and top left of screen after kwin restarted
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: XembedSNIProxy (show other bugs)
Version: 5.4.3
Platform: openSUSE Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL: https://imgur.com/UZpwWob
Keywords: usability
: 375686 400855 409396 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-01-02 19:25 UTC by Linus Kardell
Modified: 2023-05-22 09:02 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.18.0
Sentry Crash Report:


Attachments
Rendererror on my system (24.74 KB, image/png)
2017-03-14 21:15 UTC, Alex
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Linus Kardell 2016-01-02 19:25:36 UTC
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
Comment 1 Thomas Lübking 2016-01-02 22:15:27 UTC
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.
Comment 2 Linus Kardell 2016-01-03 00:53:24 UTC
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.
Comment 3 Martin Flöser 2016-01-03 08:39:55 UTC
can you check whether an application called "xembedsniproxy" is running?
Comment 4 Linus Kardell 2016-01-03 13:35:28 UTC
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.
Comment 5 Oswald Buddenhagen 2016-07-24 17:35:57 UTC
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).
Comment 6 David Edmundson 2017-03-06 23:44:52 UTC
*** Bug 375686 has been marked as a duplicate of this bug. ***
Comment 7 Alex 2017-03-14 21:15:48 UTC
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?
Comment 8 Alex 2017-03-14 21:18:16 UTC
debian stretch, plasma-workspace 5.8.4
Comment 9 Daniel Roschka 2018-06-10 06:03:25 UTC
Using Debian/unstable, that bug still occurs. Apparently BasKet 2.10-beta and KeePassX 2.0.3 need xembedsniproxy and cause the black squares.
Comment 10 Patrick Silva 2019-03-30 20:48:47 UTC
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
Comment 11 Nate Graham 2019-07-24 16:33:43 UTC
*** Bug 409396 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2019-07-24 16:49:21 UTC
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.
Comment 13 Konrad Materka 2019-10-10 10:34:02 UTC
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
Comment 14 David Edmundson 2019-10-10 12:00:51 UTC
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
Comment 15 Nate Graham 2019-11-04 20:59:46 UTC
*** Bug 400855 has been marked as a duplicate of this bug. ***
Comment 16 Konrad Materka 2019-11-29 08:39:50 UTC
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
Comment 17 Patrick Silva 2019-12-03 17:16:18 UTC
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.
Comment 18 Konrad Materka 2019-12-03 19:44:31 UTC
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.
Comment 19 Konrad Materka 2020-01-07 13:08:13 UTC
Another attempt:
https://phabricator.kde.org/D26395
Comment 20 Konrad Materka 2020-01-08 16:06:27 UTC
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
Comment 21 Alex 2020-10-08 16:55:45 UTC
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.
Comment 22 Nate Graham 2020-10-08 16:57:44 UTC
The bug was fixed in 5.18.0. :)
Comment 23 Marcin Kasperski 2023-05-22 09:02:49 UTC
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).