GNOME Bugzilla – Bug 677329
Missing focus-in events
Last modified: 2016-08-31 17:41:49 UTC
There's some weird behaviour in the reporting of focus-in events that looks like a bug to me. In gdk/x11/gdkdevicemanager-core-x11.c (and elsewhere) a HAS_FOCUS macro is used to see if a widget has focus. This is true if either has_focus or has_pointer_focus is true for the widget. Sometimes, the first focus in event is for the pointer. That is initially, the widget handle by _gdk_device_manager_core_handle_focus has has_focus = 0, has_pointer_focus = 0 but after the event has_focus = 0, has_pointer_focus = 1 however, this is NOT treated as a focus in event. Then the subsequent "real" focus in event, which changes from has_focus = 0, has_pointer_focus = 1 to has_focus = 1, has_pointer_focus = 1 does not get passed on, because the value of HAS_FOCUS (widget) does not change. This behaviour causes problems in Evince, in combination with the Awesome window manager. If i have evince open, with the mouse over it, then pretty reliably, when i switch desktops and back, the pointer focus in event comes first. The result is that Evince never realises it has focus again, and ignores all keypresses. Apologies if this is an Evince bug.
This is on the git version of gtk+ (but has been around for a while).
This behavior also causes problems with dwm (and I heard with spectrwm). It is not restricted to Evince but causes problems with all GTK3 apps - it does not always have this impact though, most of the time there simply is no focus indicator but typing into input fields or pressing space to activate a button works. The reason this behavior works in GTK2 is, that GTK2 also reacts to EnterNofity and LeaveNotify events. GTK2 also sends focus change events in case the pointer enters the window and GTK2 thinks it runs without a window manager (which is the case with all non-reparenting window managers). When I compared both toplevel->has_focus and toplevel->has_pointer_focus in _gtk_device_manager_core_handle_focus() and would send an event if either of the two change, the focus problems didn't occure any more. I don't know though if this is the best solution.
This bug is much more serious than simply invisible text cursors and focus rectangles on widgets in focused windows; it also breaks things like focus-out signals (and maybe focus-in as well, but I haven't checked) for widgets inside the toplevel window. Applications that rely on those events with callback functions stop working whenever this bug is hit.
Created attachment 221857 [details] [review] Makes focus handling work without window managers It seems the two lines introduced to handle_focus_change() in gdk/x11/gdkeventsource.c prevent the focus change events from beeing sent. This fixes the focus handling with GTK3 apps for me with dwm as well as without any window manager at all. I tried to find a commit that added these lines. It seems these lines were part of gdkeventsource.c since its addition. This check was not part of gdkevents-x11.c when it was replaced in commit bd4609b14042a91646cd9057764eecfbc6faf42b.
I can confirm this issue, and that the patch provided by ecki-gnome fixes the problem. A quick way to duplicate the problem (at least with a window manager using sloppy focus) is to open any vte3 terminal on a workspace, switch to an empty workspace and open another terminal, and finally switch back to the original workspace (so that focus will land on the original terminal). The cursor will be hollow (no focus-in event is sent to vte) and things like setting urgency don't work anymore.
By the way, this is definitely present in 3.4.4 (not just git).
Thanks ecki-gnome for the patch. Hopefully we can get this fixed (it's super annoying for me since i use Evince while latex-ing for work).
This seems to be present in all window managers using sloppy focus *excluding* gnome-shell with it enabled (i3, xmonad, dwm, awesome, [...]). So there is likely a workaround that other window managers can use. However, it really seems like gtk is the problem because no other applications or toolkits have this issue.
Hi, it's been a month since the last message. This bug has been reported on other distributions. It's affecting a lot of different people, some examples: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679738 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656032 https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/890784 Please try the patch suggested.
I have experienced this bug using GTK 3.6 and awesome wm using click-to-focus. I can repeat it in the following way: Have a window open, say "Gnome Terminal" and another window, say "Gedit". Focus the terminal and hover the mouse over it then switch to another desktop. Move the mouse so that it is not where the terminal would be. Switch back to the first desktop. The terminal will have the focus but it will not appear to be focused. To get it back into a good state, click on the window, hover the mouse over the window, switch to another desktop and then switch back. The terminal will appear focused again. Note that it doesn't have to be a terminal, it affects all gtk3 windows. The problem is in the xinput2 handling. If you export "GDK_CORE_DEVICE_EVENTS=1" then the problem goes away (this uses the gtk2 style input instead of xinput2). The following is an execution of the above steps with logging inserted into _gdk_device_manager_core_handle_focus and handle_focus_change to log the calls and the windows state. Firstly, using awesome wm (the troublesome case): """ _gdk_device_manager_core_handle_focus called with 1 NotifyNonlinear NotifyNormal has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 _gdk_device_manager_core_handle_focus: focus changed from 0 to 1 has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyInferior NotifyNormal has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyNormal has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 handle_focus_change called with GDK_ENTER_NOTIFY has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 event->detail=3 event->focus=0 _gdk_device_manager_core_handle_focus called with 0 NotifyAncestor NotifyGrab has_focus=1 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyVirtual NotifyGrab has_focus=1 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus: focus changed from 1 to 0 has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyAncestor NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyVirtual NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus: focus changed from 0 to 1 has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 handle_focus_change called with GDK_LEAVE_NOTIFY has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 event->detail=3 event->focus=0 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyWhileGrabbed has_focus=0 has_pointer_focus=1 has_pointer=0 has_focus_window=0 _gdk_device_manager_core_handle_focus called with 0 NotifyInferior NotifyWhileGrabbed has_focus=0 has_pointer_focus=1 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyWhileGrabbed has_focus=0 has_pointer_focus=1 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyVirtual NotifyUngrab has_focus=0 has_pointer_focus=1 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyUngrab has_focus=1 has_pointer_focus=1 has_pointer=0 has_focus_window=1 """ Secondly, running awesome wm with GDK_CORE_DEVICE_EVENTS=1: """ _gdk_device_manager_core_handle_focus called with 1 NotifyNonlinear NotifyNormal has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 _gdk_device_manager_core_handle_focus: focus changed from 0 to 1 has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyInferior NotifyNormal has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyNormal has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 handle_focus_change called with GDK_ENTER_NOTIFY has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 event->detail=3 evfoc=0 _gdk_device_manager_core_handle_focus called with 0 NotifyAncestor NotifyGrab has_focus=1 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyVirtual NotifyGrab has_focus=1 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus: focus changed from 1 to 0 has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyAncestor NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyVirtual NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus: focus changed from 0 to 1 has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 handle_focus_change called with GDK_LEAVE_NOTIFY has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 event->detail=3 event->focus=1 handle_focus_change: focus changed from 1 to 0 has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 event->detail=3 event->focus=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 _gdk_device_manager_core_handle_focus called with 0 NotifyInferior NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyVirtual NotifyUngrab has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus: focus changed from 0 to 1 has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyUngrab has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 """ The only difference between these two runs is that when handle_focus_change is called with GDK_LEAVE_NOTIFY, the event->focus is 1 using the core device and 0 using xinput2. I then decided to see why it works when using xinput2 in Mutter: """ _gdk_device_manager_core_handle_focus called with 1 NotifyNonlinear NotifyNormal has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 _gdk_device_manager_core_handle_focus: focus changed from 0 to 1 has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyInferior NotifyNormal has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyNormal has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 handle_focus_change called with GDK_ENTER_NOTIFY has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 event->detail=3 event->focus=0 _gdk_device_manager_core_handle_focus called with 0 NotifyAncestor NotifyGrab has_focus=1 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyVirtual NotifyGrab has_focus=1 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus: focus changed from 1 to 0 has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyNonlinear NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 0 NotifyNonlinearVirtual NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=1 handle_focus_change called with GDK_LEAVE_NOTIFY has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=0 event->detail=3 event->focus=0 handle_focus_change called with GDK_ENTER_NOTIFY has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 event->detail=3 event->focus=0 handle_focus_change called with GDK_LEAVE_NOTIFY has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=0 event->detail=3 event->focus=0 _gdk_device_manager_core_handle_focus called with 1 NotifyNonlinear NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 _gdk_device_manager_core_handle_focus called with 0 NotifyInferior NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyVirtual NotifyUngrab has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus: focus changed from 0 to 1 has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 _gdk_device_manager_core_handle_focus called with 1 NotifyAncestor NotifyUngrab has_focus=1 has_pointer_focus=0 has_pointer=0 has_focus_window=1 """ So it seems clear that the regression is due to xinput always giving an event->focus of 0 which is different from the previous device code. At this point however, I have exhausted my Xlib and window manager knowledge but cannot say exactly why it works with Mutter and not awesome and how the code should be changed to make it work with both. (I don't know what event->focus means) It also tried dwm and it manifests itself in a simpler way. Simply open a terminal, switch to an empty desktop and back again and the focus will not appear correctly. If you run without any window manager, the focus also does not appear correctly. I did try the given patch but it seemed to break focus-stuff in other ways. Hopefully this issue can get the attention of someone who knows the gdk/x11 code. Thanks
I have tested gtk master with i3 wm (a reparenting tiling window manager) with click-to-focus and sloppy focus. It has similar focus issues to dwm. So the issue is not confined to non-reparenting window managers, xlib or xcb, or sloppy focus. After testing ecki's patch, I found that it seems to fix the issue but causes windows to think that they have focus when the mouse is over them. Of course, this would not be noticeable with sloppy-focus.
I have concerns with the patch as there are situations where that change would mistakenly send focus events there on setups where there is indeed a window manager handling focus. The hint that the GDK_CORE_DEVICE_EVENTS envvar has an effect indicates that this is an XI bug, concretely the "focus" field in XIEnterEvents is invariably set to FALSE. From what I see in xserver code, DeviceEnterLeaveEvent() in http://cgit.freedesktop.org/xorg/xserver/tree/dix/events.c#n4565 doesn't deal with the ELFlagFocus flag as the CoreEnterLeaveEvent() function above does. I'll make a patch for that.
Thanks for the "GDK_CORE_DEVICE_EVENTS=1" workaround, I have been typing my mails in evolutions without a text cursor for at least a year now. It would be great to have a small fix that can be backported to libgtk 3.4.2 to make it into Debian wheezy. Any known downsides of "GDK_CORE_DEVICE_EVENTS=1"?
(In reply to comment #13) > Thanks for the "GDK_CORE_DEVICE_EVENTS=1" workaround, I have been typing my > mails in evolutions without a text cursor for at least a year now. It would be > great to have a small fix that can be backported to libgtk 3.4.2 to make it > into Debian wheezy. The fix rather belongs to xserver as indicated above, not sure what version wheezy has, but the fix looks small enough > > Any known downsides of "GDK_CORE_DEVICE_EVENTS=1"? Most visible is no tablet/touchscreen support and no smooth scrolling on touchpads. Less visibly, it's using a piece of legacy code in GTK+
FYI, http://lists.x.org/archives/xorg-devel/2013-February/035331.html
Thanks, Carlos !
Testing Carlos’ patch here now, seems to fix the problem so far.
Thanks for the patch. However, it has issues when using awesome in click-to-focus mode. See my post to the xorg-devel mailing list: http://lists.x.org/archives/xorg-devel/2013-February/035333.html
(In reply to comment #18) > Thanks for the patch. > > However, it has issues when using awesome in click-to-focus mode. That's a strange behavior indeed, it'd be great if you could track the behavior difference with core events (GDK_CORE_DEVICE_EVENTS=1), I'd pay special attention to event->focus in the terminal with B's there, if it's getting TRUE after the desktop switch it'd be quite wrong (I assume it's the terminal on the left which is really getting keyboard input, right?). Also, please double check you don't have the gtk+ patch attached here compiled in your tree, this would certainly happen with that patch. I'll get to installing and testing with awesome wm during the weekend
Yes, it was the terminal on the left that gets the input focus. I don't have any gtk patches, that was done with the stock gtk3 package on Arch Linux (currently 3.6.4). Here is a log using xinput2 and doing what was in the video: event crossing with focus=1 handle_focus_change called with 1 has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 event->detail=3 event->focus=1 handle_focus_change: focus changed from 0 to 1 has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 event->detail=3 event->focus=1 event crossing with focus=1 handle_focus_change called with 0 has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 event->detail=3 event->focus=1 handle_focus_change: focus changed from 1 to 0 has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 event->detail=3 event->focus=1 Here is a log using GDK_CORE_DEVICE_EVENTS=1: handle_focus_change called with 1 has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 event->detail=3 event->focus=1 handle_focus_change: focus changed from 0 to 1 has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 event->detail=3 event->focus=1 _gdk_device_manager_core_handle_focus called with 0 NotifyPointer NotifyWhileGrabbed has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 _gdk_device_manager_core_handle_focus: focus changed from 1 to 0 has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=0 _gdk_device_manager_core_handle_focus called with 0 NotifyPointer NotifyUngrab has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=0 _gdk_device_manager_core_handle_focus called with 1 NotifyPointer NotifyGrab has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=0 _gdk_device_manager_core_handle_focus called with 1 NotifyPointer NotifyWhileGrabbed has_focus=0 has_pointer_focus=0 has_pointer=1 has_focus_window=0 _gdk_device_manager_core_handle_focus: focus changed from 0 to 1 has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 event crossing with focus=1 handle_focus_change called with 0 has_focus=0 has_pointer_focus=1 has_pointer=1 has_focus_window=0 event->detail=3 event->focus=1 handle_focus_change: focus changed from 1 to 0 has_focus=0 has_pointer_focus=0 has_pointer=0 has_focus_window=0 event->detail=3 event->focus=1 I'm also attaching the diff against 17a3325b2 that gave the above debug output. Thanks
Created attachment 235531 [details] [review] Debug prints
After some more testing with 6a690211f, doing the same procedure in the video with logging the enter/leave and focus in/out events received for terminal B shows: When using GDK_CORE_DEVICE_EVENTS=1: EnterNotify xcrossing->focus=1 FocusOut detail=NotifyPointer mode=NotifyWhileGrabbed FocusOut detail=NotifyPointer mode=NotifyUngrab When using xinput2: XI_Enter xev->focus=1 These events all occur when changing the back to the original tag (desktop). It seems like either the client is not registered for the correct events when using xinput2, or more likely, the xserver is not sending the correct events when using xinput2. Any ideas?
Missing focus in/out events can be seen in gnome-terminal too, as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=947847 With certain window managers, if another application is closed when the mouse is over gnome-terminal, the gnome-terminal windows stops receiving focus in/out events for good. This has the annoying user-visible consequence that the mouse cursor doesn't become outlined or doesn't start/stop blinking correctly on focus in/out. (See that bug for details.) The patch over here is a good starting point figuring out what's going on. With this patch gnome-terminal's behavior is consistent from the start, closing another application while the mouse is over gnome-terminal doesn't change it. The problem is: mouse enter events are mistakenly reported as focus in.
Summarizing the current status: Carlos's patch from comment 15 looks good and it really doesn't seem to miss anything. It's already included in mainstream xorg and my xorg installation also contains that fix. Ross's comment 18 is valid: There are still problems with (at least) click-to-focus mode. GDK_CORE_DEVICE_EVENTS=1 really makes the bug go away. I'm using the following scenario to reproduce the bug: Open gnome-terminal and xterm, make xterm have the focus, move the mouse over gnome-terminal, exit xterm by pressing Ctrl+D. I guess all other ways of reproducing are just as equally good. Matthew's original post points out a pretty good location where the bug is likely to be found.
My findings so far: The default (xi2) and coredevice cases are quite different. In my test case where I trigger the bug, the old coredevice method sends focus in+out events to the window that's never focused. The new xi2 method doesn't send these, only a mouse enter event which makes much more sense. This means that it's probably not a good approach figuring out what xi2 does differently from coredevice and make it work like that. Instead, we should focus on xi2 only and find the bug. Under "normal" operation, has_pointer_focus stays 0 all the time, no matter if you enter or leave the window. Is this intended this way? What's the intended semantics of this variable? gdk/x11/gdkeventsource.c:handle_focus_change() always returns on the "if (!event->focus || toplevel->has_focus_window)" condition, never gets into setting has_pointer_focus or firing any event. When the bug arises, however, then the conditions are such that the method doesn't return halfway, has_pointer_set is flipped to TRUE, and it stays so even through subsequent incoming focus in/out events. This, combined with the original report's observations, leads to no focus in/out events being fired towards widgets. Ross's comment 10 seems to explain how to do the opposite too (to get this value back to FALSE), I haven't tried yet. Based on these, it really looks like a Gtk+ bug to me (not xorg). To be continued...
(In reply to comment #25) > This means that it's probably not a good approach figuring out what xi2 does > differently from coredevice and make it work like that. Instead, we should > focus on xi2 only and find the bug. > Another approach could be to determine why tiling window managers (like awesome and others) have the bug that I described and stacking wms like openbox do not. They must be doing something different.
Sorry for forgetting about this bug so long... From my testing, there indeed seems to be some difference between the FocusIn/Out events sent during focus window switch. I've been able to reproduce this with a variation of the use case mentioned in comment #23: - With gnome-shell, click to focus - Have 2 xterms opened - launch xinput test-xi2/xev from one - click to focus the second xterm and place the mouse on top of xinput/xev window - control-D on the focused xterm, the focus will come back to the first xterm window - control-C xinput/xev on the first xterm On core events (xev), we get: FocusIn event, serial 33, synthetic NO, window 0x8600001, mode NotifyNormal, detail NotifyPointer FocusOut event, serial 33, synthetic NO, window 0x8600001, mode NotifyNormal, detail NotifyPointer Whereas in XI2 (xinput test-xi2), we get: EVENT type 9 (FocusIn) device: 3 (3) windows: root 0x9e event 0x8600001 child 0x0 mode: NotifyNormal (detail NotifyPointer) flags: [same screen] buttons: modifiers: locked 0 latched 0 base 0x4 effective: 0x4 group: locked 0 latched 0 base 0 effective: 0 root x/y: 113.00 / 621.00 This is all prior to the focus events generated by the WM onto the xterm window, so on core events, these two events set and unset has_pointer_focus, while on XI2 it is only set to never be unset, so there is indeed something fishy in how NotifyNormal focus events are sent on XI2 (OTOH, not sure if this focus flashing is intentional, even on core events). This indeed deserves some investigation on the Xserver code, Nevertheless, I'm attaching a gtk patch to avoid those checks if there is a EWMH compliant WM managing window focus, that should make GTK+ behave fine on the most common situation regardless of this mishap, and AFAICS it was only meant to kick in in that case anyway.
Created attachment 278415 [details] [review] x11: Avoid setting has_pointer_focus if a EWMH compliant WM is present This is mostly useful to have focus behave sanely on lack of WM, so avoid any check there if we're positive there is a WM handling focus.
I forgot to mention, testing is most welcome, I couldn't reproduce or test on all setups.
Hi Carlos, Unfortunately your patch doesn't fix the problem for me :( Details: * run Unity (default desktop of Ubuntu Trusty) * gnome-terminal is updated from git, set to have blinking (dconf /org/gnome/desktop/interface/cursor-blink) and/or block (gnome-terminal's own preferences) cursor * your patch applied to Gtk+-3.10.8 * ./configure --prefix=/home/egmont/GTK && make && make install * (from xterm) LD_LIBRARY_PATH=/home/egmont/GTK/lib /usr/lib/gnome-terminal/gnome-terminal-server --app-id x.y * (from another xterm) gnome-terminal --app-id x.y * move the 2nd xterm over gnome-terminal * gnome-terminal's focus is now non-blinking outlined, since it's not focused * ^D to exit xterm * gnome-terminal's focus becomes blinking block, even though it's still not focused
(In reply to comment #30) > Unfortunately your patch doesn't fix the problem for me :( That's very strange... could you check on your compiled GTK+ that x11_screen->wmspec_check_window is effectively non-NULL when that happens? The other possibility to get the has_pointer_focus flag set is on https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdevicemanager-core-x11.c#n843 , but having that happen regularly on Unity would be even stranger (AFAIK that check is meant to catch transitions between managed and unmanaged focus).
(In reply to comment #31) > That's very strange... could you check on your compiled GTK+ that > x11_screen->wmspec_check_window is effectively non-NULL when that happens? The NotifyPointer case never occurs. Checking at the top of the method: wmspec_check_window is indeed always nonzero. > The > other possibility to get the has_pointer_focus flag set is on > https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdevicemanager-core-x11.c#n843 > , but having that happen regularly on Unity would be even stranger (AFAIK that > check is meant to catch transitions between managed and unmanaged focus). Interestingly, when the buggy behavior starts happening (i.e. when the I close the xterm window which is on top of gnome-terminal), the _gdk_device_manager_core_handle_focus() is not called at all.
Hi Carlos, Friendly ping: this issue got forgotten again... is there any chance you could please take another look and see if you manage to fix it (or at least come up with new ideas to try)? Seems like you're the most competent guy here. We're planning to add a new feature to gnome-terminal: it would raise a notification when a command in a non-active window/tab completes (bug 711059). It would be very bad if this message occasionally got omitted because we'd incorrectly think that the window is focused -- in my opinion, expecting notifications that sometimes get swallowed is worse than not having any notification system implemented at all. So practially that cool new work-in-progress feature is blocked by this bug.
(In reply to Egmont Koblinger from comment #33) > Hi Carlos, > > Seems like you're the most competent guy > here. Hey, thanks! :-) > We're planning to add a new feature to gnome-terminal: it would raise a > notification when a command in a non-active window/tab completes (bug > 711059). It would be very bad if this message occasionally got omitted > because we'd incorrectly think that the window is focused -- in my opinion, > expecting notifications that sometimes get swallowed is worse than not > having any notification system implemented at all. So practially that cool > new work-in-progress feature is blocked by this bug. Once again, every application on the desktop is using the 'active window' state to show backdrop and many other ui changes. The terminal seems to be the only one where this bug is a major issue. Why is that ?!
(In reply to Egmont Koblinger from comment #33) > We're planning to add a new feature to gnome-terminal: it would raise a > notification when a command in a non-active window/tab completes (bug > 711059). It would be very bad if this message occasionally got omitted > because we'd incorrectly think that the window is focused -- in my opinion, > expecting notifications that sometimes get swallowed is worse than not > having any notification system implemented at all. So practially that cool > new work-in-progress feature is blocked by this bug. I sort of casually looked into this again a few days ago, and came up to the same thinking that my last patch here is about the only thing gtk+ can do to improve here. One punctuation to your previous comment: (In reply to Egmont Koblinger from comment #32) > (In reply to comment #31) > Interestingly, when the buggy behavior starts happening (i.e. when the I > close the xterm window which is on top of gnome-terminal), the > _gdk_device_manager_core_handle_focus() is not called at all. If this is the case, then the gnome-terminal X Window is not receiving any focus event when the xterm window is closed. This either means the window manager is transferring the focus somewhere else, or is just not focusing anything after. Either way, this seems to me unexpected behavior and/or a bug in the WM. After this patch is applied, the course of action to figure this out would be tracing the XSetInputFocus/XISetFocus calls on your WM.
(In reply to Matthias Clasen from comment #34) > > Seems like you're the most competent guy here. > > Hey, thanks! :-) "here" -> I meant among those who were active in this bugreport :-) Don't take any offense please! You might have worked on this bug, but that's invisible to me. > Once again, every application on the desktop is using the 'active window' > state to show backdrop and many other ui changes. The terminal seems to be > the only one where this bug is a major issue. Why is that ?! I haven't noticed a difference in backdrop. I don't personally care too much if the cursor keeps blinking or if its shape doesn't change. Other bugreports (there were a few) prove that some other guys do care about these though. For me and/or for the terminal this is _not_ a major issue right now. It is _going to be_ a major issue if we implement notifications that only pop up for inactive windows. I don't want any notification accidentally not appear because we incorrectly believe the window is focused when in fact it's not. I've already described that I believe assuming a notification would arrive when in reality it never arrives is a severe bug, potentially causing a lot of time wasted. Currently this bug is blocking us from _reliably_ implementing notifications from non-active terminals, and I'm not happy implementing it in a not-that-reliable way. (In reply to Carlos Garnacho from comment #35) > [...] Either way, this seems to me unexpected behavior and/or a > bug in the WM. > > After this patch is applied, the course of action to figure this out would > be tracing the XSetInputFocus/XISetFocus calls on your WM. I don't have enough knowledge to tell whether the bug is in X, in Gtk+, or in the WM (note: in that case in multiple WMs). As comments 2 & 8 point out, neither Gtk+ version 2, nor any other toolkits have this bug, only Gtk+ v3, which makes Gtk+ quite suspicious. The explanation could also easily be that there's a misunderstanding of the specs across various components, in which case it'll be really tricky to agree on who's misinterpreting it. Whatever the case, it'd be great to have a thorough technical understanding and reasoning so that we could file bugreports against X or against multiple WMs. Proof of concept patches against X or against several infected WMs would be even better. Either of you guys have a much better understanding of this area than I do, so -- subject to your free capacity of course -- you could do a much better job in locating the culprit than I could do, even if that turns out to reside outside of Gtk+.
Review of attachment 278415 [details] [review]: I don't know what the original symptoms of this bug is, but this gtk+ patch definitely helps with bug 725342 (See https://bugzilla.gnome.org/show_bug.cgi?id=725342#c49 for steps to reproduce.)
Created attachment 321036 [details] [review] x11: Avoid setting has_pointer_focus if a EWMH compliant WM is present This is mostly useful to have focus behave sanely on lack of WM, so avoid any check there if we're positive there is a WM handling focus. --- A second patch covering further this issue, the approach is fine but was lacking further checks elsewhere. This patch works ok with gnome-terminal as far as I could try on an ubuntu VM.
Attachment 321036 [details] pushed as d55b815 - x11: Avoid setting has_pointer_focus if a EWMH compliant WM is present
Wow, I can't believe that we have a solution after so many years :) Thanks a lot, Carlos!!! I've verified on Unity (Ubuntu Wily). Could you please cherry-pick the fix to gtk-3-18, and even better, perhaps take care of releasing another tarball? I think it's quite an important fix to deserve this.
Just for reference: This bug is also responsible for bug 725342 (comments 49, 64-65; although one could argue that vte is poorly coded there and it wouldn't have occurred if it was coded differently).
Can someone help? I'm reading in a number of the threads that this bug is fixed. However, I'm baffled as to what has to be done to apply this fix. Thanks in advance if someone can share some light on this. If there is a way that a user can have the fixed version, I'll pass on this valuable information to other forums which are reporting this problem. I would love to be able to use gnome-terminal again! -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames
Hi. This is fixed by the patch in attachment #321036 [details]. If you're anxious to get this fix before your distro upgrades GTK+, you'll need to build GTK+ with that patch applied.
(In reply to Michael Catanzaro from comment #43) > Hi. This is fixed by the patch in attachment #321036 [details]. If you're > anxious to get this fix before your distro upgrades GTK+, you'll need to > build GTK+ with that patch applied. Thanks, Michael, for your input on this subject. I am very hopeful, that someone is contributing to my gap in this resolution. I'm sure it's very common knowledge of what has to be done to apply this patch. But while it's common knowledge, I'm hoping the steps might be posted somewhere. I have already studied the patch. But I can't figure out what to do to actually apply. I have used patches in the past to apply to binary files. I have also used patches to apply to source files. Originally it wasn't clear to me if this patch is to be applied to the binary or to the source. Also, the patch link makes a reference to X11. So will I have to get the source to X11? Or the source to gnome-terminal. In getting the source... which is most likely the source to gnome-terminal, can you link me to the one that this patch is built on? Also, I know there are options in the Ubuntu repository to get package sources. I'm a little confused as to whether that would work, since it's my impression that various distros and distro versions sometimes uses a different versions of the same package. Hopefully someone from this community will help shed light on this with me. Once I do it once, as I mentioned in other threads that is associated with this bug, I'll have the resolution and share it with others who might be having similar problems. -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames
Providing general support for compiling the software stack is out of scope for this specific bug report. :) Many GNOME developers use https://wiki.gnome.org/HowDoI/Jhbuild to compile software but your distribution might also offer you some instructions how to compile packages (and their dependencies) yourself.
(In reply to André Klapper from comment #45) > Providing general support for compiling the software stack is out of scope > for this specific bug report. :) Many GNOME developers use > https://wiki.gnome.org/HowDoI/Jhbuild to compile software but your > distribution might also offer you some instructions how to compile packages > (and their dependencies) yourself. I'm asking for support for my distribution. I already replied to the message about waiting for a distro upgrade, which might or might not have the bug. I'm asking for some source of what the actual patch is being applied to. If it out of your support scope to provide a link to the source that you are applying the patch to... not a distro version, but the actual source? Thanks for at least having given some input. By the way, I'm not asking for help in compiling. I do that all the time. In fact when I first started in Linux, I started out before there were any know distros, everything that was on my computer in the early 90's were compiled by me. So I won't have any problems with the actual compiling. All I need is a link to the source that would receive the patch. If I could have this, the community might even benefit by my working with the patched version. I could at least report if it actually works in the Ubuntu environment. Hopefully that could show enough value to have a shared link to the source that you guys are working with. -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames
Larry, sorry, but your lengthy comments add nothing, read: NOTHING to the topic. This is a bugtracker. We report, analyze, hunt and fix bugs here, and try to do that in the most effective way. This is NOT a support forum. André clearly told you this, and Christian also warned about this in bug 725342 comment 40, and hereby I'm also warning you. Please respect this. This bug is already fixed and will sooner or later arrive at your distribution. If it's not good enough for you, please seek help on the proper community forums (perhaps a new question on one of the stackoverflow sites, e.g. askubuntu) where hopefully someone will find the time and patience to help you. Please don't get this personal, but you're simply asking your questions on the wrong forum. Don't try to convince us to change our minds, don't continue spamming this bugtracker, instead go and find the proper forum. And don't be offended if people who are skilled enough to improve GNOME for millions of people may not be the ones who stop to help lost individuals - it's just by far not the best use of their time.
@Larry: See http://packages.ubuntu.com/search?suite=wily§ion=all&arch=any&keywords=libgtk&searchon=names and ftp://ftp.gnome.org/pub/gnome/sources/gtk+/
(In reply to Egmont Koblinger from comment #47) > Larry, sorry, but your lengthy comments add nothing, read: NOTHING to the > topic. This is a bugtracker. We report, analyze, hunt and fix bugs here, and > try to do that in the most effective way. > > This is NOT a support forum. > > André clearly told you this, and Christian also warned about this in bug > 725342 comment 40, and hereby I'm also warning you. Please respect this. > > This bug is already fixed and will sooner or later arrive at your > distribution. If it's not good enough for you, please seek help on the > proper community forums (perhaps a new question on one of the stackoverflow > sites, e.g. askubuntu) where hopefully someone will find the time and > patience to help you. > > Please don't get this personal, but you're simply asking your questions on > the wrong forum. Don't try to convince us to change our minds, don't > continue spamming this bugtracker, instead go and find the proper forum. And > don't be offended if people who are skilled enough to improve GNOME for > millions of people may not be the ones who stop to help lost individuals - > it's just by far not the best use of their time. Actually I do take your lengthy dis-invite of my participation personally. I understand that you don't care to help. I offered what I have to this bug fix and a lot of my time and efforts to the community. Yes, I asked where was the patch to be applied. If it were so out of order, I didn't pursue it in this forum. I only responded to messages, such as this one as my availability to contribute to the community. I resent your reference to my participation as spam. I appreciate your reference to suggest other forums for support in applying the patch. I also appreciate your reference that you don't care to help. But boasting your high level of expertise over mind in such to say my participation is spam would have best been left out. I won't ask for assistance, but after the patch is applied to Ubuntu 15.10 and most likely 16.04, by me, I hope you won't bash me too hard for confirming the results.
(In reply to André Klapper from comment #48) > @Larry: See > http://packages.ubuntu.com/ > search?suite=wily§ion=all&arch=any&keywords=libgtk&searchon=names and > ftp://ftp.gnome.org/pub/gnome/sources/gtk+/ Thanks! -- L. James -- L. D. James ljames@apollo3.com www.apollo3.com/~ljames
If it saves anyone any time, the fix was cherry-picked to the gtk-3-18 branch as commit 1d0ca716a12e3 and is included in the 3.18.9 release.
I am still seeing this bug. I built VTE with --enable-debug from master (commit 3c56e2cb17), built GTK+ from tag 3.20.6, and built gnome-server against those from some commit shortly after 3.20.0 (commit f096856). I run the Archlinux distro. I see the problem in ratpoison and twm. I can reliably make gnome-terminal lose track of focus in twm: 1) run "VTE_DEBUG=events gnome-terminal-server --app-id my.foo.Terminal" 2) start "gnome-terminal --app-id my.foo.Terminal" 3) wiggle the move cursor back and forth across one of the borders of the gnome-terminal window until badness.* (You need the app-id so you don't connect to your usual gnome-terminal. I launched all this from xterm so that wasn't an issue) * Eventually the (text) cursor inside gnome-terminal stops going hollow when the cursor leaves the window, which is the visible symptom that the application thinks it has keyboard focus when it really doesn't. I don't need to click in gnome-terminal or press any keys to make this happen. The nice thing about twm for the purpose of this experiment is focus *slavishly* follows mouse. When the cursor is over the root window, root has focus, by golly. So wiggling the cursor across the border causes lots of focus in/out events. I made sure ~/.twmrc was an empty file. Normally, as the cursor enters the gnome-terminal window I see a "Focus in" debug message from the server. Similarly for exiting the window and "Focus out" message. The fault occurs when the cursor enters the window, I see a "Focus in" message, the cursor leaves the window, but I don't see a "Focus out" message. Forever after gnome-terminal thinks it has focus (until I start a new gnome-terminal, of course). If this bug is re-opened, perhaps the title should change? Maybe I don't know what I'm talking about, but it looks to me like it's a matter of "Missing focus-*out* events" (instead of focus-in). I confirmed with GDB that the focus_out callback stops getting called. I put a breakpoint in VteTerminalPrivate::widget_focus_out which was hit every time the cursor left the window before focus got lost and then the breakpoint stopped getting hit after that last "Focus out" message went missing in action.
@Kenny Stauffer I am on up-to-date date Arch running stock GNOME DE (gtk3 3.20.6-1) and I also still see this bug with gnome-terminal.
(In reply to Kenny Stauffer from comment #52) > I [...] built gnome-server That should have been "gnome-terminal".
Another drive-by debugging effort from 2011, if that helps: https://mail.gnome.org/archives/gtk-list/2011-December/msg00061.html
I'm also seeing this on Debian still: libgtk-3-0:amd64 version 3.14.5-1+deb8u1, and gnome-terminal version 3.14.1-1+deb8u1.
.. though a little late I notice a fix is indicated in 3.18, so perhaps an upgrade from jessie to stretch is in order. Will maybe give that a try.