x11docker --xpra on Wayland: apps like chromium, virtualbox, etc. create menus/popups that appear out of place and disappear

[jcalfee]

x11docker --xpra on Wayland: Chromium menus/popups appear out of place and disappear

Setup: Fedora (Wayland host), Podman backend, linuxserver/chromium image. Command: x11docker --backend=podman --xpra -I -- --shm-size=10g -- linuxserver/chromium chromium-browser --no-sandbox

v7.8.0

Issue: In --xpra seamless mode, Chromium hamburger menu and right-click contexts flash briefly at top-left of host screen, get decorations, then auto-close. Can't use menus.

Workaround: Force xpra client to X11 backend with GDK_BACKEND=x11 xpra attach ... (reported to work in the issue below). But x11docker auto-launches client without easy way to inject this env. Prefix -- GDK_BACKEND=x11 -- doesn't propagate reliably to host client. Patching script locally hard-codes it, but fails due to no Xorg on Wayland host (manual xpra needs X setup?).

Related: Xpra issue: Xpra-org/xpra#4246 (comment) (confirms GDK_BACKEND=x11 workaround for Wayland client popup bugs).

Request: Add option to pass env vars (e.g., --xpra-client-env=GDK_BACKEND=x11) to host-side xpra client for better Wayland support. Or auto-detect Wayland host and force X11 client.

Can x11docker help set up Xorg in this case? Perhaps a higher-level workaround like --xpra-xorg?

I've tried every alternative you've suggested, and other than --hostdisplay (which has become much more complicated on the latest Fedora), xpra is the only option that works well for day-to-day use. There's just this one bug that's a showstopper.

It seems the developers need to figure out how to properly find the parent window, but they lack the necessary API in Wayland. Since Wayland is being adopted and enabled by default in new distros, this issue is becoming unavoidable.

Logs/verbose output available if needed. Thanks!

[mviereck]

Hello, nice to see you again, and thanks for the report.

As a quick fix it should work to run with WAYLAND_DISPLAY= x11docker --xpra [...]. Than x11docker will use the Xwayland display if available.

The Wayland/xpra issue itself can only be fixed within xpra, I have no idea what x11docker could do about it.

Maybe I should set --xpra to GDK_BACKEND=x11 by default if an Xwayland display is available. That should solve the issue without adding further options.

Xorg should not be needed at all in a Wayland+Xwayland setup, not sure why you got messages about Xorg in your fix attempts.

[jcalfee]

This works: WAYLAND_DISPLAY= x11docker --xpra [...] .. I have something usable! I picked up xorg somewhere, that is my confusion. Yes, thanks! Great to see you here again too. I just need to set a scale factor. Neither seem to use the --gpu but that is another topic. The WAYLAND_DISPLAY= with --force-device-scale-factor=2 (monitor dependent) is perfectly clear while the xpra without WAYLAND_DISPLAY= was bury. Let me know if there is something else you want me to test.

[mviereck]

x11docker has a --scale option supported with --xpra. Setting --scale=2 or --scale=0.5 should give you what you need.

You said that only --xpra provides useful results. --hostdisplay often causes issues, ok. But all other X server options should be fine in general. If you report some issues about them, that would help me.

If you have issues with the --gpu flag, please report them, too. --xpra-xwayland supports --gpu. Meanwhile it can work with NVIDIA, too, depending on system setup. However, NVIDIA and Wayland is still not great.

This article helped me to set up NVIDIA for Wayland: https://wiki.debian.org/NvidiaGraphicsDrivers#Wayland_configuration . However, I've switched back to nouveau after some time.

[jcalfee]

O yes, I see some GPU activity --xpra-xwayland .. The other issues likely were not for you. It is usability, I tend to have many windows seamless and resizing are important so I ruled out a lot due to that.

x11docker's --scale=2 had they same blurring effect. The scale factor at the app level has no quality loss.

I will reach out if I see anything else.

[jcalfee]

I may have something. This starts just fine:

WAYLAND_DISPLAY= /home/user/bin/x11docker --backend=podman --share ~/Downloads chromium-trixie chromium-browser

But when I add a sshfs shared folder "Downloads", it times out waiting for the process to start.

WAYLAND_DISPLAY= /home/user/bin/x11docker --backend=podman --share ~/Downloads chromium-trixie chromium-browser

grok claims it is this line: Error: crun: cannot stat /proc/self/fd/15: Permission denied: OCI permission denied in https://pastebin.com/97xi9Hy3

I'm not so sure. In the container I can see across the link, read write, and list files, etc:

$ podman run -it  --rm -v ~/Downloads:/downloads -- alpine sh
/ # cd /downloads/
/downloads # ls |wc -l
61
/downloads # >t
/downloads # rm t

[jcalfee]

--xpra-xwayland is not in the README.. I'm planning my setup. I will setup my defaults to use both --gpu and --xpra-xwayland if the container should have the GPU or just --xpra if not.