GNOME Bugzilla – Bug 750244
GDK_FOCUS_CHANGE event doesn't get signaled when we lose keyboard focus but still have pointer focus with XInput2
Last modified: 2018-04-15 00:14:08 UTC
When signaling a focus event from X11, there are checks in gdkdevicemanager-core-x11.c to ensure that we only send a GDK event if the focus state changes. Currently, a toplevel window having focus is defined by: #define HAS_FOCUS(toplevel) \ ((toplevel)->has_focus || (toplevel)->has_pointer_focus) On the X11 event implementation without XInput2, pointer focus is always equal to keyboard focus, so this isn't an issue. However, if a window loses keyboard focus without pointer focus on XInput2, we will never receive a GDK_FOCUS_CHANGE event as the focus state does not change as defined by HAS_FOCUS.
Hi Andrew, Sorry for my poor English, I tried to understand what you described: 1. old school X11 ***without*** XInput2 extension http://www.x.org/wiki/guide/extensions/#index2h2 pointer focus = kbd focus 2. modern X11 with XInput2 or even libinput kbd focus CHANGE (lose focus) || without-pointer-focus, then why never receive the GDK_FOCUS_CHANGED event any more? can you attach a simple testcase to make me clear, thanks a lot! Regards, Leslie Zhai
Created attachment 304635 [details] [review] DEBUG gdk x11 backend HAS_FOCUS Hi Andrew, I pay some attention to the function _gdk_device_manager_core_handle_focus https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdevicemanager-core-x11.c#n801 I argue that compare HAS_FOCUS(toplevel) with had_focus is able to work https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdevicemanager-core-x11.c#n889 Please patch it to print out toplevel->has_XXX_focus and relative values, thanks a lot! Regards, Leslie Zhai
Just run some application developed by Gtk-3-16 in your terminal, to see HAS_FOCUS situation https://twitter.com/xiangzhai/status/606743376273096704
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new