keyboard input lost after switching workspaces - 4.4 regression

[Martin-Buchholz]

Start a remote xterm using xpra. key input works. Switch to another (xfce) workspace. Switch back to the workspace containing the xpra xterm. Key input stops working, i.e. keystrokes no longer have any effect.

Both client and server are running xpra v4.4-r31576 (g2a6c16e5c) beta
Client running Ubuntu 22.04; Server running Pop OS 22.04

( host=lempel display=51; set -eux; ssh $host "rm -rf /run/user/\$UID/xpra/$display"; xpra start --start-child='xterm' --exit-with-children --ssh='/usr/bin/ssh -A -Y' -d ssh,server,keyboard,focus ssh://$host/$display; )

Perhaps it's better described as "when the X window is unmapped and then remapped, keyboard input is no longer working"

Here's debug output, showing that focus is working, and xpra is attempting to send keystrokes

2022-07-25 10:47:10,832 _unfocus() wid=1, focused=1
2022-07-25 10:47:30,266 on_enter_notify_event(ClientWindow(1), <Gdk.EventCrossing object at 0x7f62f8e06d90 (void at 0x55e33d06e950)>)
2022-07-25 10:47:30,266 may_autograb() server-mode=X11 seamless, autograb(['shadow', 'desktop', 'monitors'])=False
2022-07-25 10:47:30,272 focus-in-event for wid=1
2022-07-25 10:47:30,272 do_xpra_focus_in_event(<Gdk.EventFocus object at 0x7f62f8e079c0 (void at 0x55e33d06ea90)>) been_mapped=True
2022-07-25 10:47:30,273 ClientWindow(1) focus_change(ClientWindow(1), <GParamBoolean 'has-toplevel-focus'>) has-toplevel-focus=True, _been_mapped=True
2022-07-25 10:47:30,273 recheck_focus() wid=1, focused=1, latest=True
2022-07-25 10:47:30,274 _focus() wid=1, focused=1
2022-07-25 10:47:30,300 recheck_focus() wid=1, focused=1, latest=True
2022-07-25 10:47:30,300 _focus() wid=1, focused=1
2022-07-25 10:47:35,380 parse_key_event(<Gdk.EventKey object at 0x7f62f8e0c720 (void at 0x55e33d06e9f0)>, True)=KeyEvent(modifiers=[], keyname=Return, keyval=65293, keycode=36, group=0, string=
, pressed=True)
2022-07-25 10:47:35,381 handle_key_action(ClientWindow(1), KeyEvent(modifiers=[], keyname=Return, keyval=65293, keycode=36, group=0, string=
, pressed=True)) wid=1
2022-07-25 10:47:35,381 key_handled_as_shortcut(ClientWindow(1), 'Return', [], True) shortcuts_enabled=True, shortcuts=None
2022-07-25 10:47:35,381 send_key_action(1, KeyEvent(modifiers=[], keyname=Return, keyval=65293, keycode=36, group=0, string=
, pressed=True))
2022-07-25 10:47:35,468 parse_key_event(<Gdk.EventKey object at 0x7f63280f3790 (void at 0x55e33d06eb30)>, False)=KeyEvent(modifiers=[], keyname=Return, keyval=65293, keycode=36, group=0, string=
, pressed=False)
2022-07-25 10:47:35,469 handle_key_action(ClientWindow(1), KeyEvent(modifiers=[], keyname=Return, keyval=65293, keycode=36, group=0, string=
, pressed=False)) wid=1
2022-07-25 10:47:35,469 key_handled_as_shortcut(ClientWindow(1), 'Return', [], False) shortcuts_enabled=True, shortcuts=None
2022-07-25 10:47:35,470 send_key_action(1, KeyEvent(modifiers=[], keyname=Return, keyval=65293, keycode=36, group=0, string=
, pressed=False))
2022-07-25 10:47:43,969 on_leave_notify_event(ClientWindow(1), <Gdk.EventCrossing object at 0x7f63280f3790 (void at 0x55e33d06ea90)>) crossing event fields: {'detail': <enum GDK_NOTIFY_NONLINEAR_VIRTUAL of type Gdk.NotifyType>, 'focus': False, 'mode': <enum GDK_CROSSING_NORMAL of type Gdk.CrossingMode>, 'subwindow': <GdkX11.X11Window object at 0x7f62f8e61540 (GdkX11Window at 0x55e33cef0dd0)>, 'type': <enum GDK_LEAVE_NOTIFY of type Gdk.EventType>, 'window': <GdkX11.X11Window object at 0x7f63280aa040 (GdkX11Window at 0x55e33cef08f0)>}
2022-07-25 10:47:43,970 focus-out-event for wid=1
2022-07-25 10:47:43,970 do_xpra_focus_out_event(<Gdk.EventFocus object at 0x7f63280f3790 (void at 0x55e33d06e950)>)
2022-07-25 10:47:43,971 ClientWindow(1) focus_change(ClientWindow(1), <GParamBoolean 'has-toplevel-focus'>) has-toplevel-focus=False, _been_mapped=True
2022-07-25 10:47:43,972 recheck_focus() wid=1, focused=1, latest=False
2022-07-25 10:47:43,973 _unfocus() wid=1, focused=1
2022-07-25 10:47:43,993 recheck_focus() wid=1, focused=1, latest=False
2022-07-25 10:47:43,994 _unfocus() wid=1, focused=1
2022-07-25 10:48:20,517 _unfocus() wid=1, focused=1

[Martin-Buchholz]

Perhaps it's better described as "when the X window is unmapped and then remapped, keyboard input is no longer working"

Supporting this theory, I tried (in xfce) "roll up window; un-roll-up" and "minimize window; restore window" and both of those also resulted in keyboard input being lost.

[Martin-Buchholz]

Disconnecting (via Ctrl-C xpra client) and then re-attaching temporarily restores keyboard input

( host=lempel display=51; set -eux; xpra attach --ssh='/usr/bin/ssh -A -Y' -d ssh,server,keyboard,focus ssh://$host/$display; )

[Martin-Buchholz]

When keyboard input is non-working, I can still interact using the mouse. Copy-paste works in both directions.

I can insert text into the xterm window, but can't figure out how to execute commands using the mouse only!

[totaam]

I'll have to install xfce to try this out.
Unmapping the window is something that is usually well supported.

[Martin-Buchholz]

I tried switching client and server machines. Connecting from Pop OS running their Cosmic flavoured gnome desktop, I can reproduce the keyboard input lost problem by "hiding" the xterm (select "Hide" in the xterm window's window manager menu) and then restore (by finding the hidden xterm via Super-Tab. "Hiding" and "minimizing" are probably synonyms.

So not specific to xfce

Curiously, unlike XFCE, switching desktops and then switching back in Pop OS did NOT reproduce the problem. So it's not just about making the window non-visible.

[Martin-Buchholz]

Today xpra auto-updated to 4.4 on both client and server and this problem returned.
(previously I had downgraded back to 4.3.4).

For me this is a showstopper. Did no one else see this? It's not xfce-specific.

[RyWT]

Hey, it's not only when switching workspaces. I use Xpra with just starting or running applications directly on a remote Linux server .
Since 4.4 I also see much of your findings as well, but furthermore I see some weird things as well.

When I fx. start Signal Desktop (for Linux), it works fine. Then switching to another local app, fx. Firefox and back to Signal, everything but the keyboard works, if I then right click, and then left click with my mouse in Signal, I can get the keyboard to work.. after a second or two.

But....

In Discord (for Linux) that part with right clicking and left clicking does not work, so there is no keyboard response at all.

First I thought it had something to do with switching away from having app's running which I attached to, to plainly start them when needed, so I tried to switch back to using Signal Desktop when I started it on the remote host, and then attached to it, but it does the exact same thing.

I'll see if I can truss the process and see if it catches anything, I already tried to see if I could catch any errors on cmdline.. but no luck so far...

... (after edit) - oh and actually, now I come to think of it... I wonder why - I - in some app's have to do the R+L click with the mouse to get the keyboard back.... don't know if that could ring any bells....

Running on debian, I just downgraded:

sudo apt-get install xpra=4.3.4-r0-1
sudo apt-mark hold xpra

It is related to 4.4 as 4.3.4 works as it should.

[totaam]

@RyWT so I installed Discord on Fedora, switched workspaces, launched Firefox (tried both in the xpra session and outside it), minimized windows, restored them, moved them up and down the window stack, etc..
At no point was I able to trigger any kind of keyboard focus problems.
Please provide more detailed steps so that I can reproduce.
Shot in the dark: someone reported that they needed XPRA_FORCE_XSETINPUTFOCUS=1 to fix some focus issues with wine apps.

[RyWT]

@totaam Well I don't use xpra with workspaces, but to launch/attach to app's remotely. I have a headless lxc container with xpra installed and discord and signal (more so I don't have to install the app's on every single machine)
But let me try out the setting and see what changes that make. I'll be back 8-)

I see this on two Debian hosts I use at home and out of town (don't think the dist is important as I use the official xpra repo)

[totaam]

don't think the dist is important as I use the official xpra repo

It can be. Distros, and in particular Debian, do mess up packages or ship broken versions.

I have a headless lxc container with xpra installed ...

Do you have a full installation or one with --no-install-recommends?
Try installing the full dependencies and see if that helps.

Perhaps this issue is related to ibus which was made the default input method in 4.4:
#2359 (comment)

[RyWT]

don't think the dist is important as I use the official xpra repo

It can be. Distros, and in particular Debian, do mess up packages or ship broken versions.

Yeah, i found that some years ago when I started using Xpra and the pre-installed version didn't work as expected, so I switched to the Xpra repository directly.

I have a headless lxc container with xpra installed ...

Do you have a full installation or one with --no-install-recommends? Try installing the full dependencies and see if that helps.

Yup, no parameters, just an 'apt-get install xpra' - so it should be a full install, and it has been upgraded as well.

Perhaps this issue is related to ibus which was made the default input method in 4.4: #2359 (comment)

I'll look into that as well. But some changes must have been made between 4.3.4 and 4.4 since it stops working. I could - though - try and remove the installation and do a fresh installation of Xpra, to see if something is missing, which doesn't follow along with a normal upgrade.

[totaam]

so it should be a full install

It depends. Many container building tools enable --no-install-recommends by default.

But some changes must have been made between 4.3.4 and 4.4 since it stops working

That link is the prime candidate.

[RyWT]

hmm the --input-method=xim didn't resolve it, looking into the XPRA_FORCE_XSETINPUTFOCUS=1 part.

... nope, that doesn't work either, that is weird.

Xpra installed the same way on both my physical Linux desktop and the LXC containers.

I run LXC containers with Linux as an operating system containerized for some years. I've had no problems running through xpra up to 4.3.4.

I tried to execute a Firefox instance on a remote physical Linux host, and I see the same there, all installed the same way, so I',m pretty sure that running Linux as LXC containers is not an issue. All hosts are using the same repo for Xpra.

/usr/bin/xpra start --dpi=96 --encoding=rgb ssh://<user>@<remotesrv> --env=LANG=da_DK --exit-with-children --start-child="firefox-esr"

I've added the console output, though it doesn't mean anything, I'll try and catch the logfiles it states in the output...

xpra_screen_output.txt

And the server.log:
server.log

[totaam]

FYI: --encoding=rgb doesn't do what you think it does, --encodings=rgb might be better but the correct way of running apps in a container is to enable mmap (shared memory), which is an order of magnitude faster than rgb. You may want to look at https://github.com/mviereck/x11docker to see how to do that.

Do I need to run a container to reproduce the bug or can I just run xpra locally?
Do I need to run Ubuntu / Debian or can you reproduce the bug with Fedora?

[RyWT]

FYI: --encoding=rgb doesn't do what you think it does, --encodings=rgb might be better but the correct way of running apps in a container is to enable mmap (shared memory), which is an order of magnitude faster than rgb. You may want to look at https://github.com/mviereck/x11docker to see how to do that.

I'll look into that, I've had some issues with GUI representation performance over the network primarily over vpn, which lead me to using rgb as encoding and found it better in all cases. For the shared memory, I'm not sure it will solve anything on that part, as the LXC where my app is running, is running on a seperate physical LXC host (I run Linux dists as a container - but it has nothing to do with docker: https://linuxcontainers.org/ )

Do I need to run a container to reproduce the bug or can I just run xpra locally?

No, I have two physical machines over a VPN connection where I also reproduced the issue. So i basically ran xpra locally between two hosts - and both of them upgraded from 4.3.4 to 4.4. It's the same way with my Linux OS container.

Do I need to run Ubuntu / Debian or can you reproduce the bug with Fedora?

I haven't tried with Fedora or any other dist (Debian is a personal perference :-) ) - I can try out Fedora on an unused machine I have. Normally I use a plain Openbox implementation to keep everything super fast and simpel - but I'll se what a full blown Fedora with GNome will handle it.

[RyWT]

Hey, a short update status - trying some things out.

I've tried out Fedora 36 with a plain Gnome installation and both with wayland and xorg, that works without any issues.

The main difference between Fedora 36 and Debian 11 for Xorg, is that Debian is running on X11R7 and Fedora is on X11R5 - Don't know if that has something to do with it (Though I have no Issue with Xpra 4.3.4). At the moment I'm trying a plain installation Debian 11 with Gnome and wayland and xorg, to see if there is something related to the desktop. I'll get back on that one, as it's installing at the moment.

Also, I can see that it is only related to the local Xpra installation on the desktop. My remote host (no matter if it is a physical host or an Virtualized Debian in LXC container) it can run Xpra 4.4 - propably because it only uses the X libraries when the app is starting.

I also tried removing Xpra on all hosts, and install it fresh following the procedure on xpra.org, and also removing any existing .xpra directories in my homedir... made no differences...

I have an update on the Debian Desktop with Gnome in a moment....

---- Update 1 ----
Okay, a plain install as well with Gnome wayland and Xorg (X11R7) works fine... There must be some things missing in my physical installation with Openbox and Xorg (R7)... gotta work on that one.... am trying to find the differences...

---- Update 2 ----
Okay, I need to dig into this further, there is clearly something missing in my Openbox installation, which get's installed with GNome. Just have to find out what. Though I still find it weird that I have had no issues with 4.3.4. Just out of the box, what are the major changes from 4.3 to 4.4 ?

[totaam]

The main difference between Fedora 36 and Debian 11 for Xorg, is that Debian is running on X11R7 and Fedora is on X11R5

No. X11R7 is meaningless, it was released in 2012.
The version of X11 in Debian is usually lagging a bit, but that's very unlikely to be the cause.

... can run Xpra 4.4

Are you saying that the problem is with the client rather than server?
ie: that an xpra 4.3.x or 4.4.x server works as long as the client is 4.3.x

.. must be some things missing in my physical installation with Openbox

Are you using openbox as window manager on your client?
And only having problems with openbox as window manager?

Just out of the box, what are the major changes from 4.3 to 4.4 ?

1 year's worth of improvements:
https://github.com/Xpra-org/xpra/releases/tag/v4.4

[RyWT]

Yes, it is as I can see, Client related, and propably a missing package somewhere.

Yes my desktop is Openbox, but I'm pretty sure that that is not the issue in itself. My guess is that in Xpra 4.4 there must be something in use, which propably is missing in my installation, but something that somehow hasn't been used in previous versions... I've been trying to debug and hold up against a plain GNome installation to see if I can find out what's missing. Once I'll find out, I'll leave a note - I know that it's nothing that can be solved in code, but in case others might see similar things, it could be a worth while mentioning what ever package to look for.

[totaam]

If it is a dependency issue, then we can add the required dependency to the packaging files.
I'm not sure that it is the case, because there were no significant changes to the packaging files - at least not in the layers related to the UI.

FWIW: I'm not seeing problems with my Bookworm VM as client, it is running the default Gnome desktop. No problems either when logging into an OpenBox or mate desktop.

[fpoto]

With 4.4-r0-1 with Mate under Lightdm... (details as per #3645)

[Martin-Buchholz]

My experience is consistent with @fpoto and @RyWT

My latest repro: I upgraded my Raspberry Pi bullseye xfce4 to 5.0 and tried connecting to myself, then minimize/restore.

( host=$(uname -n) display=51; set -eux; xpra --version; xpra start --start-child='xterm' --exit-with-children --ssh='/usr/bin/ssh -A -Y' -d ssh,server,keyboard,focus ssh://$host/$display; )

[Martin-Buchholz]

The key handling debug output when working and not working looks the same - xpra is clearly noticing keystrokes. Here is the "no effect" snippet when pressing the 'z' key

2022-10-11 15:57:38,560 parse_key_event(<Gdk.EventKey object at 0x7f547d0ea0 (void at 0x6b98210)>, True)=KeyEvent(modifiers=[], keyname=z, keyval=122, keycode=52, group=0, string=z, pressed=True)
2022-10-11 15:57:38,561 handle_key_action(ClientWindow(1), KeyEvent(modifiers=[], keyname=z, keyval=122, keycode=52, group=0, string=z, pressed=True)) wid=1
2022-10-11 15:57:38,562 key_handled_as_shortcut(ClientWindow(1), 'z', [], True) shortcuts_enabled=True, shortcuts=None
2022-10-11 15:57:38,563 send_key_action(1, KeyEvent(modifiers=[], keyname=z, keyval=122, keycode=52, group=0, string=z, pressed=True))
2022-10-11 15:57:38,734 parse_key_event(<Gdk.EventKey object at 0x7f547d0ea0 (void at 0x6b97f10)>, False)=KeyEvent(modifiers=[], keyname=z, keyval=122, keycode=52, group=0, string=z, pressed=False)
2022-10-11 15:57:38,735 handle_key_action(ClientWindow(1), KeyEvent(modifiers=[], keyname=z, keyval=122, keycode=52, group=0, string=z, pressed=False)) wid=1
2022-10-11 15:57:38,738 key_handled_as_shortcut(ClientWindow(1), 'z', [], False) shortcuts_enabled=True, shortcuts=None
2022-10-11 15:57:38,739 send_key_action(1, KeyEvent(modifiers=[], keyname=z, keyval=122, keycode=52, group=0, string=z, pressed=False))

[totaam]

xpra is clearly noticing keystrokes

This looks like a focus issue, -d focus might be better.

I could probably very easily fix this bug if I had clear and reproducible instructions, but so far the VMs I have tested on worked just fine.

[Martin-Buchholz]

My repro command line did include focus debug.

If it's a focus related bug, I would expect the mouse to also be inoperative inside the window, but I can successfully copy selection text out of the window while the keyboard doesn't work.

Here is the focus debug message snippet:

2022-10-11 22:52:24,355 on_enter_notify_event(ClientWindow(1), <Gdk.EventCrossing object at 0x7f681552c0 (void at 0x2f5e9e70)>)
2022-10-11 22:52:24,356 may_autograb() server-mode=X11 seamless, autograb(['shadow', 'desktop', 'monitors'])=False
2022-10-11 22:52:24,360 focus-in-event for wid=1
2022-10-11 22:52:24,365 do_xpra_focus_in_event(<Gdk.EventFocus object at 0x7f68155130 (void at 0x7f9000a2b0)>) been_mapped=True
2022-10-11 22:52:24,369 ClientWindow(1) focus_change(ClientWindow(1), <GParamBoolean 'has-toplevel-focus'>) has-toplevel-focus=True, _been_mapped=True
2022-10-11 22:52:24,370 recheck_focus() wid=1, focused=1, latest=True
2022-10-11 22:52:24,370 _focus() wid=1, focused=1
2022-10-11 22:52:24,412 recheck_focus() wid=1, focused=1, latest=True
2022-10-11 22:52:24,413 _focus() wid=1, focused=1

[Martin-Buchholz]

Roll Window Up followed by Roll Window Down (available in xfce4 window menu) is another way to repro.

[fpoto]

Roll Window Up followed by Roll Window Down (available in xfce4 window menu) is another way to repro.

Same for Mate under Lightdm

[totaam]

As I said above, I've tried a bunch of different window managers, including xfce and mate and couldn't reproduce the problem.
Since you use containers, can't you just share a dockerfile so that I can use that and not waste more time?

[Martin-Buchholz]

More variations on my Raspberry Pi running 64-bit Raspberry Pi OS:

I created a new pristine user without any customizations and re-tried my repro in various ways.

In both LXDE and XFCE, switching desktops, iconify/restore, and roll up/roll down can repro the problem - except for roll up/roll down on LXDE. If we could understand the difference between roll up/roll down implementations between LXDE and XFCE, that might be a clue.

I suspect my repro will work on any modern (post bullseye) Debian-derived distro running on real hardware. I don't (yet) do containers or VMs.

@totaam I expected you to have a lab full of single board computers for experiments like this.

[totaam]

I expected you to have a lab full of single board computers for experiments like this.

That would be great, and I used to have more test systems, but the current funding levels don't allow that (time and space), so virtual machines or containers is what I use for testing.

[RyWT]

Hey all - I just tried something out regarding the VM I build with GNome, I scratched it and kickstarted it the same way my physcial hosts are kickstarted, and as I normally do, I also prepared it with Openbox desktop etc... all ansible stuff, and I see the same issue as with me physcial hosts. The issue remains on the client side. The host serving the application run's fine with 4.4.

Just want to let you know.

I have no docker images, the host serving my X Apps, runs in LXC and is pure headless, but since it's - in my case - related to the client missing something - I'll keep digging into it that part. There must be a library or package I am missing, which isn't being used in 4.3.4 but which 4.4 very much would like to use :-)

[fpoto]

I have created a virtual machine using Virtualbox (Debian with Mate). It exhibits the bug. To reproduce, I just open a terminal and write xpra start ssh://user@my.box.at.work/7 --start=xterm, check that the keyboard works, switch to a different workspace, switch back, and verify that keyboard input does not work any more.

The box has a root user with password "debian12" and a "debian12" user with the same password which is in sudoers. AFAICT the only thing that depends on my environment is the "isti.cnr.it" string that I was asked during installation.

You can download the image from https://fly.isti.cnr.it/tmp/debian12.ova (3 GB)

[daniel-dona]

I can reproduce this with the last update to Xpra 4.4 in Xubuntu 22.04 (client and server).

If it helps, in a window with xfce-terminal, I'm able to get back the keyboard working just by opening some of the top bar menus...

[totaam]

It was trivial to bisect and led to 2249abd.
This is fixed in 2883f78.
The focus change boolean flag was being miscalculated.