| Summary: | Xpra breaks under kwin wayland: context menus of remote applications disappear istantaneously. Works with gnome; works on kwin as an X11 application | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Sergio <sergio.callegari> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | alex, allo, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.4 | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| URL: | https://github.com/Xpra-org/xpra/issues/4246 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Sergio
2024-06-08 13:04:57 UTC
The issue appears to be that under kwin xpra cannot determine windows parents, so there are a lot of warnings like ``` Window 0x620b98e29c30 is a temporary window without parent, application will not be able to position it on screen. ``` which correspond to the disappearing context menus. I am learning that the underlying issue is that wayland prevents applications from deciding where to position their windows (while xpra obviously needs to position the context menus windows from the remote application). So it looks like we have the n-th case of applications breaking under wayland because mechanisms are removed to force policies. Xpra does all it can to find a correct window parent, and has logic to do so summarized in https://github.com/Xpra-org/xpra/issues/4246#issuecomment-2179722073. But for some reason this works on gnome but breaks on plasma. The issue can be worked around To work around the issue, it is enough to run plasma with the X11 session or to force Xpra to run working in X11 mode (using XWayland). So once more there is a regression in the wayland session. Given the importance of Xpra in providing network transparency for graphic applications, I would say this is a serious issue and a wayland showstopper in many scenarios. From the external observer, all this is rather weird. Removing mechanisms in Wayland to anyway providing them in Xwayland leads developers put an effort in making their application work with wayland to then observe it was simply much better with Xwayland. Please, if possible, try to interact with the xpra developer to see what is going on in gnome to make xpra work (since I tend to think that kwin respects the standard here). I might be wrong, but my feeling is that the xpra developer might be experiencing some sense of frurstration in interaction with anything regarding wayland. Showing collaboration might be truly useful to fix this. The issue is not specific to the VirtualBox application. Konsole itself used via xpra when the xpra client runs as a wayland application has issues with menus too. The recently released version 6.0.2 of xpra does not fix the issue, that is indicated by the xpra developer as unlikely to be fixed/fixable from the xpra side, given that xpra works fine on gnome. Wonder if this issue should be given visibility on the Plasma/Wayland Known Significant Issues given the importance of xpra as a "universal" tool for working with remote applications and remote admin (waypipe can only be used with wayland native applications, while xpra works with any applications given that wayland native applications (most? all?) also support X11. As expected, no change with xpra 6.1 since the issue does not seem to be manageable from that side. On the xpra tracker, other users are confirming the problem. More recent versions of Xpra (6.2.3) do not fix the issue that is evidently in the way in which kwin manages the wayland protocols. Because the xpra client seems to work fine as a wayland application on gnome, and wayland is complex, there is little interest/possibility from the xpra developers in trying to triage the issue with KDE plasma without the help of kwin developers. For plasma wayland sessions, the suggestion is to force xpra to run as an X11 application via xwayland, setting XDG_SESSION_TYPE=x11 since with this setup the xpra client works fine on kwin, but obviously this is suboptimal. When the issue occurs, messages like the following one are logged: ``` Gdk-Message: 10:24:45.308: Window 0x5644b1a1ac10 is a temporary window without parent, application will not be able to position it on screen. ``` The xpra developers explain: "It seems to be a new rule that you can't have a chain of windows transient for others. All the transient windows must be transient for the top one, which is weird conceptually: in a 2 level menu, the secondary menu is attached to the first level, not to the parent window... So xpra has to try to workaround this new "feature" too. (since the X11 windows may declare the relationship in the way that makes sense)" Apparently, the way in which xpra tries to work around this works in the gnome wayland compositor but does not in kwin. Given that this is plasma+wayland specific and that xpra is a rather important piece of infrastructure to run apps remotely when they are not wayland capable (so that waypipe can be used) could it be useful to add this issue to the Plasma/Wayland Known Significant Issues page? Still an Issue in 6.3.4 and with recent xpra. I am also experiencing this issue with the latest Plasma and Xpra on Wayland. Steps to reproduce: 1) Install xpra on both server and client 2) Run "xpra start :100 --start-child=konsole" on server 3) Connect via the client 4) Try to open any of the menus and submenus on the remote Konsole 5) Notice how the menus disappear xpra v6.3-r0 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.13.0 Qt Version: 6.9.0 Graphics Platform: Wayland Graphics Processor: AMD Radeon Graphics You can also try this: Turn up focus steal prevention of kwin to the max. If you open a menu, the main window should stay focused, and you get the new menu as an own (decorated) window. I tested it with Chromium, but for konsole it is probably the same. Without focus steal prevention opening a menu that gets decorated leads to the main window losing focus, what in turn closes the menu. |