search

Xpra-org / xpra

Persistent remote applications for X11; screen sharing for X11, MacOS and MSWindows.
https://xpra.org/
GNU General Public License v2.0
1.94k stars 165 forks source link

kaptain: wrong pointer and keyboard focus for concurrent windows #2255

Closed totaam closed 5 years ago

totaam commented 5 years ago

Issue migrated from trac ticket # 2255

component: client | priority: minor | resolution: invalid

2019-04-04 17:17:50: mviereck created the issue

I have encountered an odd issue with kaptain.

kaptain is a quite old GUI frontend für CLI commands. A repository is here: https://github.com/mviereck/kaptain

Code to reproduce:

xpra start :22
xpra attach :22
DISPLAY=:22 kaptain /dev/stdin <<< 'start -> @close="exit" @fork("xterm")="xterm";'

This creates a small dialog that allows to run xterm. The xterm window does not get keyboard or mouse input and cannot be closed. It can be moved and maximized.

Other applications started with DISPLAY=:22 command are affected, too.

I've tested with and without OpenGL, with xpra-py2 and xpra-py3 and with xpra versions 2.5 and 3.0 on debian buster.

The issue seems to be special for the combination of kaptain and xpra. It works well with other X servers like Xephyr or nxagent.

This might or might not be related to https://www.xpra.org/trac/ticket/1941#comment:8

Do you have an idea?

totaam commented 5 years ago

2019-04-04 17:21:55: mviereck changed title from kaptain: wrong pointer and keyboard focus for oncurrent windows to kaptain: wrong pointer and keyboard focus for concurrent windows

totaam commented 5 years ago

2019-04-05 06:20:20: antoine changed status from new to closed

totaam commented 5 years ago

2019-04-05 06:20:20: antoine set resolution to invalid

totaam commented 5 years ago

2019-04-05 06:20:20: antoine commented

First, as I keep having to repeat this, I really hope that you already know that you should not be using the form:

DISPLAY=:NN someapp

To start applications on the xpra display, always use xpra start --start=someapp instead. If the command is a shell command, you can wrap it: --start="sh -c 'whatever shell command goes here'"

As for the bug. Running the client with -d metadata, we can see the kaptain window coming up:

process_new_common: [4, 0, 0, 104, 97, {b'xid': b'0xc00003', b'client-machine': b'desktop', b'pid': 25991, b'title': b'kaptain', \
    b'class-instance': (b'kaptain', b'Kaptain'), b'group-leader-xid': 12582917, b'window-type': (b'DIALOG', b'NORMAL'), \
    b'size-constraints': {b'gravity': 1, b'minimum-size': (104, 97)}, b'icon-title': b'', b'decorations': 30, b'modal': True, \
    b'iconic': False}], ..., OR=False

It is a DIALOG modal window, and so it will capture all input until dismissed. For details see #1895.

When forwarding multiple applications through the same xpra connection and one of the windows is modal, you need to tell xpra not to honour the modal flag for that session:

xpra attach --modal-windows=no

FYI: the latest GTK API (Gtk.Window.set_modal) still does not allow more fine grained settings than just on and off. (qt does: WindowModality but even then we wouldn't be able to specify which windows this needs to apply to).

totaam commented 5 years ago

2019-04-05 09:20:31: mviereck commented

Great, thank you! --modal-windows=no fixed it for me.

First, as I keep having to repeat this, I really hope that you already know that you should not be using the form: DISPLAY=:NN someapp

I am aware of that. However, in the context of x11docker that is not possible because the applications run in an isolated container that xpra cannot access. At least x11docker sets the environment variables that xpra sets for its clients.

Thank you for giving some insight, too! It helps me to understand what is going on.

Though, I am wondering why the issue does not appear if I run kaptain on other X servers or on display :0. I've also tried a few different window managers (kwin, xfwm4, openbox). Maybe it is common to ignore the modal flag, and only xpra honours it by default.

Just an idea: You could allow XPRA_MODAL_WINDOWS=0 to set --modal-windows=no.

totaam commented 5 years ago

2019-04-05 12:46:16: antoine commented

Maybe it is common to ignore the modal flag, and only xpra honours it by default. They do honour it, but this modal flag is per application - it just so happens that xpra ends up being multiple applications that the window manager sees as just one.

Just an idea: You could allow XPRA_MODAL_WINDOWS=0 to set --modal-windows=no. XPRA_MODAL_WINDOWS has been removed earlier today.

totaam commented 5 years ago

2019-04-05 15:25:55: antoine commented

They do honour it.. Looking at the GTK source code, they're not actually given the choice: the "modal" behaviour is enforced by GTK, it uses X11 grabs to do so. gtk_grab_add : Makes @widget the current grabbed widget. This means that interaction with other widgets in the same application is blocked and mouse as well as keyboard events are delivered to this widget. If @widget is not sensitive, it is not set as the current grabbed widget and this function does nothing.

totaam commented 5 years ago

2019-04-06 21:09:17: mviereck commented

Thanks for the additional information.

They do honour it, but this modal flag is per application - it just so happens that xpra ends up being multiple applications that the window manager sees as just one.

That makes sense, good to know.

totaam commented 5 years ago

2019-06-23 08:15:54: mviereck commented

Just a note: man xpra does not show option --modal-windows.

xpra --help shows:

    --modal-windows=MODAL_WINDOWS
                        Honour modal windows. Default: 'True'.
totaam commented 5 years ago

2019-06-23 14:05:29: antoine commented

Just a note: man xpra does not show option --modal-windows. Oops, thanks for pointing that out: fixed in r23020.