Xpra: Ticket #2270: dropdown menu not clickable

Both Client and Servers are 2.5-r22135-1 on Ubuntu 18.04 64 bit directly from xpra ubuntu PPA. Many dropdown menus cannot be selected.

For example, in the window on the client side of the chrome running on the server side, press ctrl-shfit-p to bring up the print menu, go to page setup, click on any of the dropdown menus, e.g. "page per side", I cannot select any item other than the default. This happens in many application's menu, for example in the "print" menu of Adobe Acrobat or evince.

When I use forward x11 on the same server and same client, the dropdown menu works.

Somehow the native dropdown menu on firefox and chrome works. Just those print dialogs, and perhaps some other dialogs, from gnome does not. The dropdown menu in adobe acrobat reader does not work either.

Because it happens when I click on the dropdown menu I could not take any screenshots. Please let me know if there is any more debugging I could do.

Sat, 13 Apr 2019 04:14:38 GMT - Jiang: keywords changed

For adobe acrobat, I mean the dropdown menu in the print menu, or its preference menu. In libreoffice, the preference dropdown menus, such as when you go to Tool->Options->View, none of the various click and drop menu works. So it is not merely a matter of gnome applications.

Sat, 13 Apr 2019 04:18:47 GMT - Antoine Martin: status changed

Reproducible on Fedora - which will make it easier to fix.

@jiang.qian: is this a regression? If so, is it recent? What was the last version that worked OK for you?

Sat, 13 Apr 2019 04:25:32 GMT - Jiang:

I'm not sure, unfortunately. I've just made a huge upgrade from ubuntu 14.04 to Ubuntu 18.04, which enables me to upgrade xpra from 1.0 branch to 2.5 branch. I didn't have the problem in 1.0 branch, but that's not saying much...

Please let me know what else I can do to fix it. It kind of makes printing harder to use and adjust...

Thank you for producing the *very* useful xpra! I've been using it for more than three years and it enables me to stick to my old laptop and use the remote workstation! I dare say in this way it reduce electronic waste, at least in my case...

Sat, 13 Apr 2019 06:09:45 GMT - Antoine Martin: owner, status changed


So r19869 is the "bad" commit. This is caused by modal windows (#1895). The quick workaround is to run the client with --modal-windows=no.

Here's the print dialog window from evince:

process_new_common: [8, 782, 590, 750, 519, \
     b'xid': b'0xc04419', b'client-machine': b'desktop', b'pid': 22084, \
     b'title': b'Print', b'class-instance': (b'evince', b'Evince'), b'transient-for': 6, \
     b'group-leader-xid': 12582913, b'window-type': (b'DIALOG',), b'size-constraints': {b'position': (0, 0), \
     b'base-size': (0, 0), b'gravity': 1, b'minimum-size': (750, 519)}, b'icon-title': b'Print', \
     b'modal': True, b'set-initial-position': True, b'iconic': False \
    }], \
    metadata=.., OR=False
2019-04-13 12:09:49,873 popup_types(['DIALOG'])=()

And here's a drop-down menu for that dialog:

process_new_common: [13, 901, 606, 409, 292, \
     b'xid': b'0xc04ebb', b'client-machine': b'desktop', b'pid': 22084, \
     b'title': b'Document Viewer', b'class-instance': (b'evince', b'Evince'), \
     b'transient-for': 8, b'group-leader-xid': 12582913, b'window-type': (b'COMBO',), \
     b'override-redirect': True \
    }], metadata=.., OR=True

As per _NET_WM_STATE spec: _NET_WM_STATE_MODAL indicates that this is a modal dialog box. If the WM_TRANSIENT_FOR hint is set to another toplevel window, the dialog is modal for that window; if WM_TRANSIENT_FOR is not set or set to the root window the dialog is modal for its window group. WM_TRANSIENT_FOR is set to another window (the main evince window), so it should only be modal for that window. The OR window is transient-for the modal window. My guess is that we're doing the right thing, but the OR window uses grabs (see X11: input focus for popups: Most X11 override-redirect exclusive popup windows (menus, combo boxes, ...) grab the keyboard and/or pointer with either passive or active grab) and we can't support those: ticket:139#comment:41.

So the fix for trunk is in r22384: we remove the modal flag on all windows when an OR window is shown, and we re-enable it when the OR window goes away.

For the v2.5.x branch, I have just changed the default for modal-windows to false.

@jiang.qian: does that work for you?

Sun, 14 Apr 2019 05:32:52 GMT - Jiang: status changed; resolution set

I can confirm that turning off modal window at commandline at the client side "--modal-window=no" fix the issue! Thank you for resolving it so quickly!

By the way, what does "modal window" option do anyway? I can't seem to see any difference after switching it off.

Again, thank you for fixing it!

Sun, 14 Apr 2019 06:13:17 GMT - Antoine Martin:

By the way, what does "modal window" option do anyway? I can't seem to see any difference after switching it off.

Many applications will use modal windows to prevent the user from interacting with the other application windows until they've dismissed the modal one (ie: preferences, alert dialog, etc) The option in xpra ignores the modal flag.

Thu, 23 May 2019 16:10:00 GMT - Antoine Martin:

r22384 caused a regression: #2304. (good thing this was never backported!)

Sat, 23 Jan 2021 05:46:43 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2270