"Focus model" is set to "Focus follows mouse" in Window Manager settings. "Automatically raise windows when they receive focus" is enabled.
With this configuration, even if a client grabs pointer AND keyboard focus, and now expects to exclusively receive and respond to all pointer and keyboard events, moving the pointer to another window still results in xfwm4 moving the keyboard focus to the other window, raising it on top of the client's window, then taking the keyboard focus away from an application that has successfully grabbed it.
This results in some counter-intuitive UI behavior. For example, an application window creates an OverrideDirect popup on top of itself, and grabs the pointer+keyborad (i.e. a combo-box popup). But, despite doing that, pointer activity may still result in another application's window getting raised on top of the application window, but behind the popup (since OverrideRedirect popups seem to be always stacked on top of non-overridden windows). The results are ugly -- another application window gets crammed between this application that has the pointer grabbed, and its popup. But, the application still continues to receive grabbed pointer and keyboard events.
If a window grabbed the pointer/keyboard, it's reasonable for the window to believe that it's the only one that's processing keyboard/pointer events, and it should not have pointer/keyboard focus taken away from it. Another argument is that nothing else should be receiving and responding to pointer events while somebody is holding a pointer grab -- including the window manager. That's what a pointer grab is supposed to be.
This behavior can be demonstrated with the following short example. This example waits two seconds, to get its top window drawn, then grabs the both the pointer AND the keyboard for 30 seconds and then logs all motion events and keyboard events.
Moving the pointer continues to log motion and keyboard events even when the pointer leaves the window that grabbed the pointer. But, moving the pointer to another window results in another window now acquiring keyboard focus and xfwm4 raising that window, which could then cover the window that grabbed the pointer+keyboard -- and it continues to receive grabbed pointer events, apparently, but not keyboard events, it lost keyboard focus.
So, I have a window that grabbed both the pointer and the keyboard focus, but it still ends up losing the keyboard focus. Given that focus-follow-mouse affects both the pointer and keyboard events, a good argument can be made that this function should be disabled if some client has the pointer or the keyboard grabbed.
xcb_connection_t *conn=xcb_connect(NULL, NULL);
xcb_grab_pointer(conn, 0, wid,
while (t < expiration)
struct pollfd pfd;
if (poll(&pfd, 1, (expiration-t)*1000) < 0)
if (pfd.revents & POLLHUP)
if ((event->response_type & ~0x80) == XCB_MOTION_NOTIFY)
if ((event->response_type & ~0x80) == XCB_KEY_PRESS)
-- GitLab Migration Automatic Message --
This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/315.
Please create an account or use an existing account on one of our supported OAuth providers.
If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests
Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev