Related to #2255 Seen with xpra v3.0.8-r25889 and xpra v4.0-r25629 on Debian bullseye.
I have an application (kaptain) that sets the modal-windows flag and causes issues with keyboard and mouse focus. Disabling modal windows fixes the issue.
I did not set --modal-windows=no, so I had to disable it in the xpra tray menu. But that does not fix the issue. I also have to re-initialize the windows using the tray menu. xpra should do that automatically.
Side note: Although I reported #2255 myself, I stumbled over the modal-windows issue again and it took me some time to figure out why the windows do not respond. For some days I used ssh -X instead of xpra because xpra was unusable. It might be reasonable to set --modal-windows=no as a default because the solution for this issue is not obvious to users.
Done in r25928.
We've had problems with modal windows (#1895) in the past: #2270, #2304. But by not honouring the modal window flag, we're likely to encounter other bugs... The only way to avoid all these bugs is to only forward a single application per xpra session.
Thank you!
Please note that I've also pointed on an xpra issue. Though, it might be obsolete now:
I had to disable [modal windows] in the xpra tray menu. But that does not fix the issue. I also have to re-initialize the windows using the tray menu. xpra should do that automatically.
Only disabling "Modal Windows" in the tray menu was not enough. xpra should automatically re-initialize the windows.
Replying to Antoine Martin:
The only way to avoid all these bugs is to only forward a single application per xpra session.
I would like to see how would that work in the future.
Maybe you could have a session that's not bound by screens (and instead is bound on some string), and then xpra could use >:2000 displays to host windows as-requested?
... but then you don't know which processes will spawn windows to split them
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2706