dropdown menu not clickable

[totaam]

Issue migrated from trac ticket # 2270

component: server | priority: major | resolution: fixed | keywords: dropdown menu

2019-04-13 04:52:46: jiang.qian created the issue

---

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.

[totaam]

2019-04-13 05:14:38: jiang.qian commented

---

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.

[totaam]

2019-04-13 05:18:47: antoine changed status from new to assigned

[totaam]

2019-04-13 05:18:47: antoine commented

---

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?

[totaam]

2019-04-13 05:25:32: jiang.qian commented

---

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...

[totaam]

2019-04-13 07:09:46: antoine changed status from assigned to new

[totaam]

2019-04-13 07:09:46: antoine changed owner from antoine to jiang.qian

[totaam]

2019-04-13 07:09:46: antoine commented

---

Bisecting:

• 2.5.x BAD
• 2.4.x BAD
• 2.3.x OK
• 20000 BAD
• 19500 OK
• r19750 OK
• r19875 BAD
• r19812 OK
• r19844 OK
• r19860 OK
• r19868 OK
• r19872 BAD
• r19870 BAD
• r19869 BAD
• r19868 OK

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: #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?

[totaam]

2019-04-14 06:32:52: jiang.qian changed status from new to closed

[totaam]

2019-04-14 06:32:52: jiang.qian set resolution to fixed

[totaam]

2019-04-14 06:32:52: jiang.qian commented

---

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!

[totaam]

2019-04-14 07:13:17: antoine commented

---

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.

[totaam]

2019-05-23 17:10:01: antoine commented

---

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