VirtualBox context menus disappear

[callegar]

Describe the bug

Trying to use VirtualBox under xpra. Encountering an issue even before launching the virtual machines. In the main VirtualBox Window, pressing the right mouse button should open a contex menu. Under xpra this context menu cannot be used: it opens and closes automatically before you can even move the mouse on it.

To Reproduce Steps to reproduce the behavior:

1. Start xpra on the server with xpra start :101 and then get a terminal on it (e.g. DISPLAY=:101 konsole)
2. Attach to the client xpra attach ssh://server/101
3. In the terminal from the server start VirtualBox
4. In the VirtualBox window go to an entry corresponding to a virtual machine, press the right mouse button to get the context menu

See the context menu appearing and disappearing before you can use it.

System Information (please complete the following information):

• Server OS: Manjaro (arch)
• Client OS: Manjaro (arch)
• Xpra Server Version 6.0.1
• Xpra Client Version 6.0.1

Additional context

Both client and server use KDE plasma 6 with a wayland session.

[totaam]

Works fine on Fedora with Gnome - could be some incompatibility with KDE.

[totaam]

.. and then get a terminal on it (e.g. DISPLAY=:101 konsole)

Don't do that. Use --start=konsole to get the correct environment setup.

[callegar]

Thanks for the advice, now using --start. Does not change the issue with the floating context menus, though. Might indeed be plasma specific or even plasma 6 specific or plasma 6 on wayland specific.

[totaam]

Does not change the issue with the floating context menus

I didn't think it would. That's a separate issue.

plasma 6 on wayland specific

Yes, that's likely. Wayland makes all sorts of window positioning issues "interesting".

[callegar]

Also reported at KDE https://bugs.kde.org/show_bug.cgi?id=488208

[callegar]

Seems 100% reproducible for me, so I hope they can check it.

[totaam]

@callegar they're probably going to say that xpra is at fault.

[callegar]

Even if it was, which may well not be, I hope they will help by looking into it. xpra is a too important piece for having it misbehave in KDE, IMHO. Furthermore, the post X era where each DE has its own implementation of the wayland protocols really requires a lot of cooperation to assure that things remain consistent across desktops.

[callegar]

Issue is actually not limited to VirtualBox. I see a similar behavior with konsole. If I go on the sandwich button and press it, then a menu appears. When I try to show a submenu, the submenu flashes and disappears. At the same time I get messages such as:

(Xpra:54999): Gdk-WARNING **: 16:14:13.755: Couldn't map as window 0x620b98e10110 as popup because it doesn't have a parent

(Xpra:54999): Gdk-WARNING **: 16:14:18.089: Tried to map a popup with a non-top most parent

(Xpra:54999): Gdk-WARNING **: 16:14:20.503: Tried to map a popup with a non-top most parent
Gdk-Message: 16:14:33.630: Window 0x620b98e29c30 is a temporary window without parent, application will not be able to position it on screen.

[callegar]

In any case, forcing the xpra client to work in X11 mode rather than in wayland mode works around the issue. Enough to do GDK_BACKEND=x11 xpra attach --ssh=ssh --dpi <dpi> ssh://<host>/<display> --start konsole.

[totaam]

I see a similar behavior with konsole

Works fine here on Fedora + Gnome Shell.

The problem comes from this: Window 0x620b98e29c30 is a temporary window without parent, application will not be able to position it on screen.

X11 applications routinely place their windows wherever they like, but Wayland decided to break the vast majority of existing applications by not providing an API for doing that (it does exist, as can be seen when using XWayland). We try hard to find a parent: https://github.com/Xpra-org/xpra/blob/28bc4c6f60d6ae46eb187314364782146cad5605/xpra/client/mixins/windows.py#L880-L893 https://github.com/Xpra-org/xpra/blob/28bc4c6f60d6ae46eb187314364782146cad5605/xpra/client/mixins/windows.py#L871-L878 And there's only so much guessing we can do without getting it wrong. Perhaps the version of VirtualBox also makes a difference: newer versions are more likely to bend over backwards to try to satisfy all these new Wayland windows relationship restrictions.

[callegar]

Unfortunately it is not only a VirtualBox problem. The fact that it affects the very default terminal application for KDE (konsole) makes it more serious. Pinging again the Kwin developers...

[callegar]

Would it be possible/sensible to default to Xwayland on Kwin plasma until this can be addressed?

[totaam]

until this can be addressed?

It's unlikely to be addressed. Requiring Xwayland will also cause other problems and packaging difficulties.

[cavedon]

I see the same issue on vscode, with the menu immediately disappearing and the log

Gdk-Message: 10:24:45.308: Window 0x5644b1a1ac10 is a temporary window without parent, application will not be able to position it on screen.

This happens for top level menus (not submenus) and the parent's override_redirect should the main application window with override_redirect set to False (correct?)

@totaam , I do not fully understand

X11 applications routinely place their windows wherever they like, but Wayland decided to break the vast majority of existing applications by not providing an API for doing that (it does exist, as can be seen when using XWayland).

Are you saying that the API exists (because it works using XWayland/GDK_BACKEND=X11) but it is not exposed via GDK when using wayland directly?

[totaam]

Are you saying that the API exists (because it works using XWayland/GDK_BACKEND=X11) but it is not exposed via GDK when using wayland directly?

Correct. It's not just GDK, it's the Wayland itself. They decided to break existing applications and expect them to change how they work. Embrace and extend has its merits, it's a shame they didn't learn from it.

[cavedon]

Given that XWayland is a Wayland client and XWayland is able to do it[1], then GDK, being a Wayland client, should be able to do it as well by using the proper Wayland API, correct? Or am missing something?

[1] "It" being "arbitrarily position a window on the screen without the need to specify its parent", correct?

Or does it work under Xwayland only because in that case GDK knows the parent, while on Wayland it does not?

[totaam]

The compositor has access to it, GDK does not.

[callegar]

@cavedon are you experiencing the issue in KDE, Gnome or some other DE? If it is KDE, then please report also at https://bugs.kde.org/show_bug.cgi?id=488208. If it is Gnome, then that is interesting, because that DE appeared to be avoiding the issue.

@totaam will something in https://gitlab.freedesktop.org/wlroots/wlr-protocols/ help with the issue? This is something likely to land in many wayland compositors. Or is something in https://github.com/probonopd/wayland-x11-compat-protocols needed? Guess it is less likely to see something like this landing in major compositors, but who knows.

[totaam]

Anyone can follow the bike shedding going on here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 Meanwhile, there will not be a year of the Linux Desktop, they've made sure of that.

[severtheskyline]

Anyone can follow the bike shedding going on here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 Meanwhile, there will not be a year of the Linux Desktop, they've made sure of that.

Look at what ext-zones says:

The initial protocol proposal which used absolute monitor-based coordinates was NACK'ed by Weston (and GNOME later), so it is in the ext namespace now.

I like wayland, but if an irrelevant compositor and a compositor that explicitly ignore standards (like xdg-decoration for server side window decorations) can have so much authority over everyone else, well damn, you aren't lying.

[fabiscafe]

@severtheskyline They don't have. App devs are in control here to only support compositors that implement the necessary extensions. For Server side Decoration this was clear relatively early on that it wont be a core protocol, to ensure that an app provides all the functionality required by itself. Apps might need a minimize button or a maximize, close or even other things that a server side window decoration might not provide, because its not important to its own usage pattern.

We had this on X11 and it wasnt working for anything that was not a standard Desktop PC. Like entertainment systems, where apps in theory could be launched, but there was no way to close them, because that wasnt the design pattern for those devices, but the app had requirements on the window decorations to provide those. Limiting apps that are usable to those that are directly build for the devices instead of "everything dumped to flathub".

You can say: Wayland is not not the protocol for Desktop PCs. It only happens to be popular on them.

[totaam]

@fabiscafe - please try to put yourself in the shoes of application developers

App devs are in control here to only support compositors that implement the necessary extensions.

The fact that app devs will not be able to have the correct behaviour on most Wayland compositors is not being "in control", quite the opposite. Telling these devs: "your apps are not welcome here" is not helpful. And it's not helping the Linux desktop for sure.

SSD... to ensure that an app provides all the functionality required by itself

Having the well documented end result that every app's window decoration can look and behave differently, that's not a win by any stretch of the imagination. Removing features used by every other OS out there is not an improvement. And again, does not help the Linux desktop.

We had this on X11 and it wasnt working for anything that was not a standard Desktop PC

Just because some apps don't need the desktop PC paradigm doesn't mean that you shun those that do by not providing the features they have always relied on. No one was forced to use the window decorations.

Like entertainment systems..

You have this completely backwards. Those apps have always been free to implement their own UI, without using SSD. Having the option to use SSD, just like every other OS has, does not prevent them from doing that. Not having this option makes the Linux desktop far less attractive for application developers.

You can say: Wayland is not not the protocol for Desktop PCs. It only happens to be popular on them.

It is not "popular". Linux desktops account for a tiny fraction of the overall desktop PC market, and within that tiny percentage, Wayland is a fraction of that. That is not "popular". And judging by the difficulty imposed on application developers, it likely never will be a target platform for apps either.

[callegar]

As expected, no change with 6.1. Noticed a funny thing, though. With "konsole" some context menus do appear, some others do not, some make xpra say "Tried to map a popup with a non-top most parent", which is unclear to me if it is a different issue or the same.

[totaam]

some make xpra say "Tried to map a popup with a non-top most parent"

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)

[callegar]

There is now frog protocols. Could it be useful to try to see if that design space can be useful to try to improve the user experience with xpra (the client side) on wayland?

[allo-]

Also affects Chromium on kwin_wayland. #4563 Good to know it's kwin specific, but in the end I'd consider kwin one of the better WMs.

[totaam]

See also (vscode, focus, etc): #4526, #4484, #1436, #4631