SUMMARY Kwin appears to behave differently wrt other window managers with the result of breaking xpra (https://github.com/Xpra-org/xpra), an application for using X11 applications from remote. I have the following configuration: Server: Manjaro linux, KDE plasma 6 with wayland session Client: same Running xpra 6.0.1 (latest) on both machines. On the server I start xpra as a server managing the "virtual" display :101. Then I start applications in X11 mode using DISPLAY=:101. On the client I start xpra to attach to the server. The xpra client works as a GTK3 application in the wayland session. Now, I start VirtualBox on the server on the :101 display. The Virtualbox window is correctly shown in the client. However, if I right click to open a contextual menu, the menu opens and disappears immediately, without letting me use it. I am being told from the xpra developer that this behavior is not experienced on other desktops. See https://github.com/Xpra-org/xpra/issues/4246 STEPS TO REPRODUCE 1. Have 2 hosts 2. Assure that they both run a plasma 6 wayland session 3. Assure that xpra is installed on both 4. Assure that Virtualbox is installed on one of them that will be the server 5. On the server run `xpra start :101` 6. On the client run `xpra attach ssh://server/101 --start konsole` 7. On the client see a remote konsole from the server appear 8. In the remote konsole type `VirtualBox` to start virtualbox on the server 9. See the Virtualbox window appear on the client 10. Right click on some object in the Virtualbox window to make a context menu appear OBSERVED RESULT See the context menu appear and immediately disappear EXPECTED RESULT The context menu should remain visible until it is used or erased. SOFTWARE/OS VERSIONS Operating System: Manjaro Linux KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.2-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Celeron® N4120 CPU @ 1.10GHz Memory: 5.6 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 600 Manufacturer: CHUWI Innovation And Technology(ShenZhen)co.,Ltd Product Name: Hi10 X ADDITIONAL INFORMATION Tested with a server that is the same configuration but Intel haswell hardware Also seen with a client that is the same configuration but Zephyrus Rog 14 AMD Ryzen + rembrandt graphics. Xpra is 6.0.1 Virtualbox is 7.0.18
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?