forward input grabs to the client

[totaam]

Issue migrated from trac ticket # 139

component: core | priority: minor | resolution: wontfix

2012-06-04 14:37:48: ahuillet created the issue

---

Hello,

some applications, in particular games, grab the mouse pointer and keyboard input. This is needed e.g. when you play a first-person-shooter (where you aim with the mouse) in a window. In this case you expect the mouse to stay inside the game's window. This behavior is broken in Xpra.

See SDL_GrabMode X11_GrabInputNoLock(_THIS, SDL_GrabMode mode) in SDL's source code for how it's done - the X11 functions seem to be the following two:

• XGrabPointer

• XGrabKeyboard

Calling those must, I assume, give some kind of feedback to the WM that we can use to forward the grab commands to the client.

[totaam]

2014-02-03 14:22:08: antoine uploaded file pointer-grab-stub.patch (1.3 KiB)

captures NotifyGrab and NotifyUngrab events

[totaam]

For some background, see: A High-Level Overview of Grabs and X11 Input Event Processing

As per Window Entry/Exit Events and Grab Processing, the [/attachment/ticket/139/pointer-grab-stub.patch] allows us to see when the client application requests a pointer grab and when it releases it.

We get those events on the composite helper because it recursively selects addXSelectInput on all the window's parents as part of the damage handle code... and the event is delivered to a parent window we aren't managing. This is a bit nasty.

Anyway, once we get one of those events, we can keep track of which window is meant to get all input, and make sure we deliver the events there. We can also forward the grab state to the client, which can try to honour it... For example, with gtk: gtk.gdk.pointer_grab and gtk.gdk.pointer_ungrab
But because this is all over the network and asynchronous, I'm not sure how well this can work.

For the keyboard, the events would be: Input Focus Events. (I think keyboard grabs are a lot less important than pointer grabs)

[totaam]

2014-02-03 15:54:16: antoine uploaded file pointer-grab-v1.patch (7.5 KiB)

implements pointer grabbing in gtk2

[totaam]

2014-02-03 16:00:30: antoine commented

---

The patch [/attachment/ticket/139/pointer-grab-v1.patch] works surprisingly well in my limited testing, even on win32. Anything that shows a drop down menu is likely to trigger this, for testing see:

• floating menu + keyboard focus - input grabs #336: any application with menus
• [/browser/xpra/trunk/src/tests/xpra/test_apps/test_drop_down.py test_drop_down] (just select the drop down menu, then click on a non xpra window)
• [/browser/xpra/trunk/src/tests/xpra/test_apps/test_context_menu.py test_context_menu] (right click in the text input, then click on a non xpra window)

Please test more thoroughly (browser drop downs, context menus, etc), I am not committing this yet because this can cause complete display lockups if we grab the pointer without ungrabbing it...

Please also check if we can reverse r5176 (see #490) - in which case I would do a partial revert: only use the ugly osx workaround for servers that do not support grabs.

[totaam]

2014-02-04 04:56:15: totaam uploaded file pointer-grab-v2.patch (11.0 KiB)

better patch, should prevent client grab lockups

[totaam]

Much cleaner implementation merged in r5346 (will make it easier to test): instead of coopting the composite helper, we create a new helper class, better able to track what we want.

[totaam]

2014-02-07 20:36:37: maxmylyn commented

---

Tested it in Win7 using r5383 and got the following behavior:

• test_drop_down.py will disappear as expected when shifting focus away, but only by clicking in another window. Alt-tabbing will leave the drop-down up.
• right clicking in test_context_menu.py and clicking in another window(xpra or non-xpra) will make it disappear. However alt-tabbing out and into another window (xpra or non-xpra) will cause the drop-down to remain until you click in a xpra window.

Using Chrome I went to http://interfacelift.com/wallpaper/downloads/date/any/ and clicked on an arbitrary drop-down(I use this site a lot as the drop-down menus are quite large) and got the following behaviour:

• Drop downs won't disappear if you change focus to a different window in Windows.
• Clicking in another Xpra window(in my case Chrome and Firefox), the drop-down disappears as expected.
• Simply Alt-Tabbing out won't make it disappear, it'll stay up until you click in another Xpra window. In the local Chrome, alt-tabbing out of a window will cause the same drop-down to disappear.

Repeating the same test in Firefox, everything works as expected. Both alt-tabbing and clicking out causes the same drop-down to disappear.

[totaam]

All the issues with Alt-Tabbing away are due to the fact we don't grab the keyboard, and until I can figure out how to get keyboard grab events from the X11 server, it will remain this way.

Which only leaves:

Drop downs won't disappear if you change focus to a different window in Windows

Is this by clicking? (the other sentences mention click or alt-tab explicitly, this one does not) How does this differ from the positive results posted above it?

Note: I have now reverted r5176 in r5396 (see #490), please re-test to ensure that the behaviour has not regressed.

[totaam]

Update: the keyboard grabs don't do anything on win32 - AFAICT there is no such thing, so I have come up with an ugly hack as an alternative:

• r5406 allows us to hook custom events
• r5407 detects when our app loses focus and we fake pressing 'Escape' on that window...
  See commit messages for more details.

This solves the Alt-Tab problem for me. AFAIK, this should only leave one question to answer from comment:9

[totaam]

• r5408 tries to ensure we ungrab when the window is closed
• r5409 adds "xpra control :DISPLAY ungrab" to force ungrab the client (could be useful if we get stuck with the grab)

[totaam]

2014-02-13 18:36:35: maxmylyn commented

---

Sorry about not being specific enough, let me clarify:

On that website http://interfacelift.com/wallpaper/downloads/date/any/ in chrome, either clicking OR alt-tabbing out of Xpra wouldn't make the drop down disappear.

Also relevant, alt-tabbing into another Xpra window won't make it disappear, only by clicking in another Xpra window makes it disappear.

edit:
Retested with r5444, behavior is still the same with interfacelift.

[totaam]

It's worse than I thought...

Running a well behaved application in the client with -d win32, I see:

callbacks for event WM_ACTIVATEAPP: [<bound method ClientExtras.activateapp of <xpra.platform.win32.gui.ClientExtras object at 0x01E7F730>>]
2014-02-14 06:47:20,809 WM_ACTIVATEAPP: 0/2700 UNGRAB_KEY=Escape, \
    client=XpraClient object at 0x1d17148 (xpra+client+gtk2+client+XpraClient at 0x104c460)>
lost focus whilst window has grab, simulating keypress: (65307, 'Escape', 27, 0, 0)

And on the server with -d keyboard:

world window lost focus
world window got focus
focus wid=20 has_focus=20
make_keymask_match(()) current mask: set(['mod2']), wanted: set([]), ignoring=9/['Escape'], keys_pressed={}
keynames(mod2)=set(['Num_Lock']), keycodes=[77], nuisance=False
make_keymask_match(remove) () modifier mod2 using 77, success: False
remove mod2 with keycode 77 did not work - trying to undo it!
handle_key(20,True,Escape,65307,9,()) keyboard_sync=True
handle keycode pressing 9: key Escape
fake_key(9, True)
cancelling key repeat timer: 9122 for Escape / 9
scheduling key repeat timer with delay 750 for Escape / 9
focus wid=20 has_focus=20
make_keymask_match(()) current mask: set(['mod2']), wanted: set([]), ignoring=9/['Escape'], keys_pressed={9: 'Escape'}
keynames(mod2)=set(['Num_Lock']), keycodes=[77], nuisance=False
make_keymask_match(remove) () modifier mod2 using 77, success: True
handle_key(20,False,Escape,65307,9,()) keyboard_sync=True
handle keycode unpressing 9: key Escape
fake_key(9, False)
cancelling key repeat timer: 9445 for Escape / 9
make_keymask_match(('mod2',)) current mask: set([]), wanted: set(['mod2']), ignoring=None/['lock'], keys_pressed={}
keynames(mod2)=set(['Num_Lock']), keycodes=[77], nuisance=False
make_keymask_match(add) ('mod2',) modifier mod2 using 77, success: True

Showing that we detect the loss of focus client side with the WM_ACTIVATEAPP event, and then press and release the Escape key on the server, causing the drop down menu to disappear. (the focus change detection code works with both clicks and alt-tab)

So all is working well and I am closing this ticket, feel free to re-open if I've missed anything.

---

The problem with chrome is different and I am moving it to #519

[totaam]

Got broken by the fixes in #556 ...

Which is annoying because r6120 added a better way of ungrabbing windows: using a dedicated packet rather than faking a keypress.

[totaam]

2014-04-20 09:07:27: totaam uploaded file fix-grabs.patch (17.2 KiB)

fixes grabs but also crashes the server with X11 errors..

[totaam]

AFAICT, the problem is that we cannot reliably determine the window which owns the grab by watching the focus NotifyGrab events.

The solution adopted in the patch attached:

• use a single grab helper instance, instead of having one per window model
• issue the grab on the window which has the focus when we get the event
  And now I have to figure out why this causes crashes running gtkperf...

For reference, here are the docs on Normal Focus Events and Focus Events While Grabbed and Focus Events Generated by Grabs

[totaam]

Applied in r6133. The crashes were due to a call to get_geometry done outside the usual X11 locking (via trap.call).

This is a server side only fix, which will not be backported to v0.12 because it is too intrusive. Grabs will remain disabled for v0.12x.

---

Please re-test, especially on OSX and platforms I tend to test less (though I did test this quite a bit with XP as client).

Applications useful to test with (many at once is even better):

• gtkperf -a (and run it in a loop)
• qt5/examples/script/calculator/calculator (and right click in text area to get the menu to show up)
• tests/xpra/test_apps/test_drop_down.py
  etc..

[totaam]

2014-04-21 23:11:37: afarr commented

---

Testing with 0.13.0 r6140 server side and 0.12.3 r6067 with both windows and osx...

• test_drop_down.py and test_context_menu.py both behave as expected.

However, testing drop down and context menus behaves differently with each browser, in each OS.

OSX.

• Google-chrome drop-down menus are appearing "behind" the chrome window, and not disappearing when clicking on a local window (though they do lose focus and disappear when clicking on another xpra session window). Note - the drop-down menu can be clicked on "through" the window which is displaying as if it had top-level focus (same as Focus issue with mouse on osx client #469 behavior). Context menus, meanwhile, get top-level focus and maintain that despite any changes of focus to local windows (they behave as expected when clicking on another xpra session window).

(Running client in -d focus mode, while testing the context menu, it looks like there is an update_focus([winID], False) _focused=[winID], where [winID]=chrome window id, while there is no sign of a focus mention of the POPUP_MENU window. Once the local window is clicked, this is followed by a send_focus(0) when focus shifts to the local window ... in case that helps.)

• Firefox drop-down menus appear as expected, but clicking on a local window while a drop-down is open causes the browser to crash (fired up in an xterm, the window disappears, but the process is still running and requires a SIGINT to clear). Context menus behave as expected.

• Lazarus drop-down menus gain top level focus and maintain it indefinitely if local windows are clicked and/or moved around the desktop - only disappearing when a click in an xpra window changes the focus (clicking focus to another xpra session window will close the drop-down menu). Context menus behave the same as drop-down menus.

Meanwhile, on windows...

• Google-chrome drop-down menus behave in the same manner as on Lazarus with OSX - the drop-down menus gain top-level focus after a local window is clicked, and maintains it however the windows are moved around the desktop. Likewise, clicking on any xpra session window will shift focus as expected and close the drop-down menu. Context menus behave as expected.

• Firefox drop-down menus behave exactly as expected, when clicking in another xpra session window or a local window. Context menus behave as expected.

• Lazarus also behaves exactly as expected, as focus shifts to other xpra session windows or local windows. Context menus behave as expected.

Many of these issues have been ongoing, but the firefox crash with OSX seems like it merits a closer look, and the apparent regression of the chrome popups appearing "behind" the window on OSX seems like it might be worth a closer look as well.

Let me know which permutations with which -d mode you'd like me to capture next.

[totaam]

Apart from the obvious one (Firefox crashing - which I will investigate further), which ones are regressions?

FYI: the debug string for grabs is: -d grab, focus is also worth having since the two are related. send_focus(0) means that the focus is not on any of our windows (0 is the default "root window").

[totaam]

2014-04-23 00:17:55: afarr commented

---

The google-chrome on OSX is a regression - where the POPUP_WINDOWs are displayed "behind" the google-chrome window (I just use facebook.com's signin page drop-downs for date of birth for checking).

A search of closed tickets reveals that it is a reversion of one of the cases of #490 (which seems to have been fixed by the [/attachment/ticket/490/focus-force-transientfor.patch]?).

As you described in #490, the chrome seems to define the popups as a NORMAL rather than transient-for window... and the server does indeed seem to then pop the chrome window to the top since the popup click is a click on that window.

Here's an excerpt from the client-side -d grab, focus output:

2014-04-22 15:14:05,961 send_focus(17)
2014-04-22 15:14:05,961 send_focus(0)
2014-04-22 15:14:08,075 using audio codec: MPEG 1 Audio, Layer 3 (MP3)
2014-04-22 15:14:12,706 focus-in-event for wid=17
2014-04-22 15:14:12,707 ClientWindow(17) focus_change((ClientWindow(17), <GParamBoolean 'has-toplevel-focus'>)) has-toplevel-focus=True, _been_mapped=True
2014-04-22 15:14:12,707 update_focus(17, True) _focused=None
2014-04-22 15:14:12,707 send_focus(17)
2014-04-22 15:24:22,260 _unfocus() wid=23
2014-04-22 15:24:35,127 focus-out-event for wid=17
2014-04-22 15:24:35,127 ClientWindow(17) focus_change((ClientWindow(17), <GParamBoolean 'has-toplevel-focus'>)) has-toplevel-focus=False, _been_mapped=True
2014-04-22 15:24:35,128 update_focus(17, False) _focused=17

Checking the xpra info | grep window output I see that wid 17=google-chrome & window[23].window-type=('NORMAL',) ... and that window has no name. (At this point, it seems irrelevant to post the xpra info output, though I certainly can if you'd like me to.)

The remainder of the issues seem to be the issue of the hovering popups which refuse to relinquish top-level focus, which was a topic from #336, but was since moved here to #139... but which I didn't think had been fully addressed (though it looks like tickets were closed, so perhaps it was an issue that only persisted with lazarus?)

[totaam]

afarr: the quoted "POPUP_MENU" and "POPUP_WINDOW" values from the comments above do not exist. As stated previously, chrome uses NORMAL.
Please do not use code blocks for unverified or guessed values. Someone might be tempted to look them up and / or assume those were correct (extracted or cut & pasted from source or log files). And more importantly, it confuses me when I try to make sense of this bug report.
Also transient-for and NORMAL are not mutually exclusive: transient-for is a flag that may be set, usually for override-redirect windows (another flag), NORMAL is one of the window-types.

[totaam]

2014-04-24 12:25:19: totaam uploaded file grab-fix-watch.patch (2.3 KiB)

watch all the client windows and use the correct event mask

[totaam]

2014-04-24 12:28:56: totaam commented

---

With the [/attachment/ticket/139/grab-fix-watch.patch grab-fix-watch.patch], grabs work again, even with chrome.

But we still have problems with osx, even some new ones:

• osx doesn't seem to honour any grabs..
• clicking on a drop down menu, it disappears instantly
• firefox disappears as per comment:19 (the description was incorrect: the browser is not crashed, just hidden)

[totaam]

2014-04-24 16:10:06: totaam uploaded file grab-fix-watch-v2.patch (13.7 KiB)

better patch, moving force ungrab code to common location

[totaam]

Things left to do:

• maybe catch NotifyWhileGrabbed and ungrab if we don't know where the grab is from? (races, missed events)
• fix OSX: either disable grabs on OSX, or find a way to get the menu window to stay on top, somehow. The former may be the easiest way to fix things, the latter is what we really want.
• maybe move the force ungrab code to the server side: adds backwards compatibility for free (we just end up detecting when the client sends an "unfocus" without first sending us an "ungrab" and workaround it generically)

[totaam]

2014-04-25 09:49:40: totaam commented

---

Mostly merged the patch as-is in r6167 (client side refactoring) and r6168 (server side changes).

Still trying to figure out the Firefox problems on OSX (which does not rely on grabs, but still belongs here because these changes broke it, or just made it worse - AFAICT).

Comparing both client and server logs (-d all heavily edited) with OSX and Linux. From the moment we click outside the Firefox window (wid=2) which has a drop down menu shown.

• server:

process_focus: wid=0
reset_focus() 2 / WindowModel(0xa00092 - "test - Mozilla Firefox") had focus (toplevel=WorldWindow(0x40001e))
focus_out_event on Firefox window, mode=NotifyNormal, detail=NotifyNonlinearVirtual
focus_in_event on World Window, mode=NotifyNormal, detail=NotifyNonlinear

With a Linux client (where the drop down disappears as expected), before we see the lost_window, we see a few:

damage Firefox

Whereas with an OSX client (where the whole window disappears), we see:

cursor_event (ignored - because on world window?)
lost_window: drop down menu
damage Firefox

Not sure why.

[[BR]]

Client side:

• Linux client (ok):

XRootPropWatcher.do_xpra_property_notify_event for _NET_CLIENT_LIST and _NET_CLIENT_LIST_STACKING
focus-out-event for wid=2
GLClientWindow Firefox focus_change has-toplevel-focus=False, _been_mapped=True
update_focus(2, False) focused=2, grabbed=None
send_focus(0)
destroy_window(the drop down window)

• OSX client:

focus-out-event for wid=2
ClientWindow Firefox focus_change has-toplevel-focus=False, _been_mapped=True
update_focus(2, False) focused=2, grabbed=None
send_focus(0)
destroy_window(the drop down window)

[totaam]

2014-04-25 09:55:14: totaam uploaded file test.html (0.1 KiB)

a much better test page to load (no ads, animations, etc - just a drop down and nothing else)

[totaam]

Much improved in r6170: removed the helper class, use the actual window grab id from the event.

In order to catch all grabs, I think we need to modify the X11 server (ouch), as it shortcuts and skips sending grab events when the window with the grab is the current one (see GrabDevice -> ActivatePointerGrab -> DoEnterLeaveEvents ..)

[totaam]

Just found out that the chrome drop down menus do set:

WM_WINDOW_ROLE(STRING) = "popup"

Which is better than nothing, and when choosing the window to use as parent we could also prefer the currently focused window (which is generally the browser window which generated the menu)

[totaam]

I tried adding this patch to the Xorg server to be able to get grab notifications (added all the code before the return in dix/enterleave.c:DoEnterLeaveEvents):

    if (fromWin == toWin) {
        if (mode == NotifyGrab)
            CoreFocusEvent(pDev, FocusIn, mode, NotifyNonlinear, toWin);
        else if (mode == NotifyUngrab)
            CoreFocusEvent(pDev, FocusOut, mode, NotifyNonlinear, toWin);
        return;
    }

We get almost too many events (passive button grabs fire for example). Useful for debugging.

[totaam]

Re-assign.

Also some new pointers / examples:

• XWindowPeer (java)
• Attempting to select submenu items under compiz after lengthy gnome-screensaver lock closes a menu. Fixed by focusing another app - suggests using RECORD extension, maybe the focus activity recording program can be useful?
• platform_window_focus forces a window to get focus on osx (could be useful)

[totaam]

2014-08-21 00:07:54: afarr commented

---

Testing with osx 0.14.0-7276 against a fedora 20 0.14.0-r7189 (trying to confirm behavior for this ticket vs. #490) ... I now find that pop-up menus no longer hold top-level focus when clicking focus over to a local application.

Works as expected with Windows and CentOS clients... and it works as expected with google-chrome on osx... but trying to click on a local application while a drop-menu is active on a firefox browser window is causing the firefox window to disappear.

Testing with the -d window flag active I saw the following logs, which seem to indicate that the window is getting a destroy command, perhaps mistakenly targeting the firefox window instead of the drop-menu window?:

2014-08-20 12:41:11,304 move_resize(31, 106, 710, 140, -1)
2014-08-20 12:41:11,305 resize(710, 140, 0)
2014-08-20 12:41:11,311 GL do_configure_event(<gtk.gdk.Event at 0x89a3b60: GDK_CONFIGURE x=31, y=106, width=710, height=140>)
2014-08-20 12:41:11,312 GLClientWindow(31 : GLPixmapBacking(31, (710, 140), None)).do_configure_event(<gtk.gdk.Event at 0x89a3b60: GDK_CONFIGURE x=31, y=106, width=710, height=140>)
2014-08-20 12:41:13,713 destroy_window(31, GLClientWindow(31 : GLPixmapBacking(31, (710, 140), None)))
2014-08-20 12:41:18,977 process_new_common: [32, 736, 601, 54, 322, {'opacity': -1, 'fullscreen': False, 'has-alpha': False, 'xid': '0xe00b53', 'pid': 14844, 'window-type': ('UTILITY',), 'maximized': False, 'transient-for': 30, 'override-redirect': True}], OR=True
2014-08-20 12:41:18,977 make_new_window(..) client_window_classes=[<class 'xpra.client.gl.gl_client_window.GLClientWindow'>, <class 'xpra.client.gtk2.border_client_window.BorderClientWindow'>], group_leader_window=<gtk.gdk.Window object at 0xd53e7b0 (GdkWindow at 0x117ac70)>
2014-08-20 12:41:18,977 GLClientWindow(..)
2014-08-20 12:41:18,977 <class 'xpra.client.gl.gl_client_window.GLClientWindow'>(<XpraClient object at 0x70db080 (xpra+client+gtk2+client+XpraClient at 0x18df240)>, <gtk.gdk.Window object at 0xd53e7b0 (GdkWindow at 0x117ac70)>, 32, 736, 601, 54, 322, {'opacity': -1, 'fullscreen': False, 'has-alpha': False, 'xid': '0xe00b53', 'pid': 14844, 'window-type': ('UTILITY',), 'maximized': False, 'transient-for': 30, 'override-redirect': True}, True, {})
2014-08-20 12:41:18,977 GLClientWindow(32 : None).apply_transient_for(30) window=GLClientWindow(30 : GLPixmapBacking(30, (1166, 949), YUV444P))
2014-08-20 12:41:18,977 set_window_type(['UTILITY']) hints=5
2014-08-20 12:41:18,978 GLClientWindow(32 : None).set_fullscreen(False)
2014-08-20 12:41:18,978 setup_window() has_alpha=False, <class 'xpra.client.gl.gl_window_backing.GLPixmapBacking'>.HAS_ALPHA=False
2014-08-20 12:41:18,978 make_new_backing(<class 'xpra.client.gl.gl_window_backing.GLPixmapBacking'>, 54, 322) effective backing class=<class 'xpra.client.gl.gl_window_backing.GLPixmapBacking'>, server alpha=False, window alpha=False
2014-08-20 12:41:18,987 GL do_configure_event(<gtk.gdk.Event at 0x89a3c98: GDK_CONFIGURE x=736, y=601, width=54, height=322>)
2014-08-20 12:41:18,988 GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)).do_configure_event(<gtk.gdk.Event at 0x89a3c98: GDK_CONFIGURE x=736, y=601, width=54, height=322>)
2014-08-20 12:41:18,988 GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)).window_state_updated(GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)), <gtk.gdk.Event at 0x89a3c68: GDK_WINDOW_STATE>) new_window_state=<flags 0 of type GdkWindowState>, fullscreen=False, maximized=False, iconified=False
2014-08-20 12:41:18,989 GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)).do_map_event(<gtk.gdk.Event at 0x89a3c68: GDK_MAP>) OR=True
2014-08-20 12:41:22,619 destroy_window(32, GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)))

[totaam]

Found Find X.org pointer grab owner which is interesting: You can do this by pressing the XF86LogGrabInfo key

[totaam]

2015-07-31 01:06:55: afarr commented

---

Tested again osx client 0.15.4 10055 against fedora 20 server 0.15.4 r10133,

It looks like the firefox is behaving the same as previously (open a pop-up, click on a local application with the pop-up open... the entire firefox window closes/crashes).

With -d window logs running client side, when I click on an outside application I get a similar destroy message:

2015-07-30 16:29:56,078 ClientWindow(6).do_map_event(<gtk.gdk.Event at 0x6bc68a8: GDK_MAP>) OR=True
2015-07-30 16:29:58,851 destroy_window(6, ClientWindow(6))

At this point the firefox window disappears, but the process doesn't seem to have ended in the xterm from whence it was launched. When I then use command-c to kill the firefox process I get indication that another window is being killed: 2015-07-30 16:51:24,910 destroy_window(4, ClientWindow(4)).

With chrome, the pop-ups behave as expected.

With a webkit based browser, like epiphany, I see the "older" behavior of the pop-up appearing as expected but not disappearing when focus is shifted to other applications (and not relinquishing top-level display focus even when other application windows are dragged "over" the pop-up, resulting in the other applications displaying as if they are being dragged "under" the pop-up).

In the case of epiphany, clicking on a pop-up generates: 2015-07-30 17:00:33,390 ClientWindow(15).do_map_event(<gtk.gdk.Event at 0x6bc6ce0: GDK_MAP>) OR=True.

Clicking on an outside application (& dragging it under the pop-up) seems to trigger the UI thread messaging:

2015-07-30 17:01:41,319 UI thread is now blocked
2015-07-30 17:01:41,320 UI thread is running again, resuming

Then clicking on one of the values of the pop-up destroys it: 2015-07-30 17:03:20,940 destroy_window(15, ClientWindow(15)) - though the value clicked on is retained in the proper field of the original window.

[totaam]

2016-07-31 17:05:16: ironiridis commented

---

Is there a branch or a less stale patch somewhere that still implements pointer grabs? Happy to offer comprehensive testing and feedback on something closer to 0.17.x, as my usage case depends on mouse-look type behavior.

[totaam]

Is there a branch or a less stale patch somewhere that still implements pointer grabs?

This is now in trunk, see #1229#comment:10.

Note: this is somewhat different from the original intent of this ticket (changed ticket title to reflect that): we don't (yet?) detect and forward when an application requests a grab, we just trigger it ourselves from a keyboard shortcut instead. Pure client side only, the server is not involved in any way and is not even aware that a grab is in effect client side.

@ironiridis: does this work for you?

[totaam]

2016-08-01 22:49:03: ironiridis commented

---

Replying to [comment:35 antoine]:

Is there a branch or a less stale patch somewhere that still implements pointer grabs?
[[BR]]
This is now in trunk, see #1229#comment:10.

Note: this is somewhat different from the original intent of this ticket (changed ticket title to reflect that): we don't (yet?) detect and forward when an application requests a grab, we just trigger it ourselves from a keyboard shortcut instead. Pure client side only, the server is not involved in any way and is not even aware that a grab is in effect client side.

@ironiridis: does this work for you?

Verified Menu key is being processed via xev. Built r13144 client with
./setup.py --without-csc_swscale --without-dec_avcodec2 --without-enc_x264 --without-enc_x265 --without-enc_ffmpeg --without-v4l2 --without-vpx --without-server --without-shadow build install --home=~/xpra/
Ran with DISPLAY=:0 xpra -d grab attach tcp:10.10.10.1:9997
Unfortunately no discernable difference. With grab logging, no events are logged when I press the Menu or Control_R keys.
Verified that r13144 is running in both console output and Xpra tray menu "About" option.

Pure client side only, the server is not involved in any way and is not even aware that a grab is in effect client side.

I didn't modify the server build at all, which is running r12942.

[totaam]

Ran with ...

Should be something like (paths may vary):

PYTHONPATH=~/xpra/lib64/python/ ~/xpra/bin/xpra ...

Otherwise you will be using the system installed version.

With grab logging, no events are logged when I press the Menu or Control_R keys.

Please attach the client output with -d keyboard,grab.
We want to verify the keyboard shortcuts are parsed correctly and that they are caught as well.

@ironiridis: can we move this to #1229, I want to keep #139 for the not-yet-implemented server grabs forwarding.

[totaam]

Important: the shortcuts have just been changed, see r13169

[totaam]

2016-08-02 13:50:20: ironiridis commented

@ironiridis: can we move this to #1229, I want to keep #139 for the not-yet-implemented server grabs forwarding.

Replied at #1229#comment:13.

[totaam]

As far as I am aware, we can only detect application requesting X11 server grabs by intercepting the API call using library tricks (ie: LD_PRELOAD), and we don't want to go down that route.
#1229 should be enough for most purposes anyway.

[totaam]

2019-04-13 07:12:33: antoine commented

---

See also #1895 and #2270.

[totaam]

Perhaps we will be able to receive grabs events after all!
#3957 (comment)