xpra icon
Bug tracker and wiki

Opened 6 years ago

Closed 10 months ago

#139 closed enhancement (wontfix)

forward input grabs to the client

Reported by: ahuillet Owned by: Antoine Martin
Priority: minor Milestone: 2.0
Component: core Version: trunk
Keywords: Cc: onlyjob@…, ironiridis+xpra@…

Description (last modified by Antoine Martin)

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:

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.

Attachments (7)

pointer-grab-stub.patch (1.3 KB) - added by Antoine Martin 4 years ago.
captures NotifyGrab? and NotifyUngrab? events
pointer-grab-v1.patch (7.5 KB) - added by Antoine Martin 4 years ago.
implements pointer grabbing in gtk2
pointer-grab-v2.patch (11.0 KB) - added by Antoine Martin 4 years ago.
better patch, should prevent client grab lockups
fix-grabs.patch (17.2 KB) - added by Antoine Martin 4 years ago.
fixes grabs but also crashes the server with X11 errors..
grab-fix-watch.patch (2.3 KB) - added by Antoine Martin 4 years ago.
watch all the client windows and use the correct event mask
grab-fix-watch-v2.patch (13.7 KB) - added by Antoine Martin 4 years ago.
better patch, moving force ungrab code to common location
test.html (138 bytes) - added by Antoine Martin 4 years ago.
a much better test page to load (no ads, animations, etc - just a drop down and nothing else)

Download all attachments as: .zip

Change History (48)

comment:1 Changed 5 years ago by Antoine Martin

Description: modified (diff)
Milestone: 0.3future
Status: newaccepted

comment:2 Changed 4 years ago by Antoine Martin

Milestone: future0.12
Status: acceptednew
Version: 0.1.0trunk

will try to deal with this as part of focus/input work in 0.12

comment:3 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

Changed 4 years ago by Antoine Martin

Attachment: pointer-grab-stub.patch added

captures NotifyGrab? and NotifyUngrab? events

comment:4 Changed 4 years ago by Antoine Martin

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)

Last edited 4 years ago by Antoine Martin (previous) (diff)

Changed 4 years ago by Antoine Martin

Attachment: pointer-grab-v1.patch added

implements pointer grabbing in gtk2

comment:5 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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:

  • #336: any application with menus
  • test_drop_down (just select the drop down menu, then click on a non xpra window)
  • 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.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 4 years ago by onlyjob

Cc: onlyjob@… added

Changed 4 years ago by Antoine Martin

Attachment: pointer-grab-v2.patch added

better patch, should prevent client grab lockups

comment:7 Changed 4 years ago by Antoine Martin

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.

comment:8 Changed 4 years ago by J. Max Mena

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.

comment:9 Changed 4 years ago by Antoine Martin

Owner: changed from alas to J. Max Mena

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.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:10 Changed 4 years ago by Antoine Martin

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

comment:11 Changed 4 years ago by Antoine Martin

  • 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)

comment:12 Changed 4 years ago by J. Max Mena

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.

Last edited 4 years ago by J. Max Mena (previous) (diff)

comment:13 Changed 4 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

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

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:14 Changed 4 years ago by Antoine Martin

Resolution: fixed
Status: closedreopened

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.

Last edited 4 years ago by Antoine Martin (previous) (diff)

Changed 4 years ago by Antoine Martin

Attachment: fix-grabs.patch added

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

comment:15 Changed 4 years ago by Antoine Martin

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

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:16 Changed 4 years ago by Antoine Martin

Owner: changed from J. Max Mena to alas
Status: reopenednew

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

comment:17 Changed 4 years ago by alas

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

comment:18 Changed 4 years ago by Antoine Martin

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

comment:19 Changed 4 years ago by alas

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 https://www.xpra.org/trac/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?)

comment:20 Changed 4 years ago by Antoine Martin

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.

Changed 4 years ago by Antoine Martin

Attachment: grab-fix-watch.patch added

watch all the client windows and use the correct event mask

comment:21 Changed 4 years ago by Antoine Martin

With the 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)

Changed 4 years ago by Antoine Martin

Attachment: grab-fix-watch-v2.patch added

better patch, moving force ungrab code to common location

comment:22 Changed 4 years ago by Antoine Martin

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)

comment:23 Changed 4 years ago by Antoine Martin

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.


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)
    
Last edited 4 years ago by Antoine Martin (previous) (diff)

Changed 4 years ago by Antoine Martin

Attachment: test.html added

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

comment:24 Changed 4 years ago by Antoine Martin

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

comment:25 Changed 4 years ago by Antoine Martin

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)

comment:26 Changed 4 years ago by Antoine Martin

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.

comment:27 Changed 4 years ago by Antoine Martin

Milestone: 0.120.14

Re-scheduling.

comment:28 Changed 4 years ago by Antoine Martin

Owner: changed from alas to Antoine Martin
Status: newassigned

Re-assign.

Also some new pointers / examples:

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:29 Changed 3 years ago by alas

Testing with osx 0.14.0-r7276 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)))

comment:30 Changed 3 years ago by Antoine Martin

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

comment:31 Changed 3 years ago by Antoine Martin

Milestone: 0.151.0

Re-scheduling, again.

comment:32 Changed 2 years ago by alas

Tested again osx client 0.15.4 r10055 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.

comment:33 Changed 17 months ago by Antoine Martin

Milestone: 1.01.1

Milestone renamed

comment:34 Changed 17 months ago by Chris J Harrington

Cc: ironiridis+xpra@… added

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.

comment:35 Changed 17 months ago by Antoine Martin

Owner: changed from Antoine Martin to Chris J Harrington
Status: assignednew
Summary: Handle input grabbingforward input grabs to the client

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


This is now in trunk, see ticket: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?

comment:36 in reply to:  35 Changed 17 months ago by Chris J Harrington

Owner: changed from Chris J Harrington to Antoine Martin

Replying to antoine:

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


This is now in trunk, see ticket: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.

comment:37 Changed 17 months ago by Antoine Martin

Owner: changed from Antoine Martin to Chris J Harrington

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.

comment:38 Changed 17 months ago by Antoine Martin

Important: the shortcuts have just been changed, see r13169

comment:39 in reply to:  37 Changed 17 months ago by Chris J Harrington

Owner: changed from Chris J Harrington to Antoine Martin

Replying to antoine:

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


Replied at ticket:1229#comment:13.

comment:40 Changed 16 months ago by Antoine Martin

Milestone: 1.12.0

Milestone renamed

comment:41 Changed 10 months ago by Antoine Martin

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.