_gdk_wm_protocols_filter steals focus
Steps to reproduce
- Open Firefox
- Open Web Console Window (by using Inspect element)
- Open another window (for example, a konsole), and place it such that it covers the top of the firefox web console
- Open another window (another konsole) and place it such that it covers the bottom of the firexfox web console, leaving a narrow gap between both where web console is visible behind them.
- Move mouse back and forth between the top and the bottom konsole, crossing the web console each time.
- Whenever you are in a konsole with the mouse, observe the cursor shape.
- Pretty quickly you see that your konsole does not have focus (hollow cursor) even the mouse is in the window.
- Press cursor keys: you see that the web console has focus!
Current behavior
Certain Gtk applications (such as firefox web console) steal focus of passing mice
Expected outcome
Gtk should not mess with the focus, but only accept it when it gets it, and not attempt to hold on to it when user tries to move on to something else
Version information
3.24.5-1
Additional information
In order to debug why this is happening, I started firefox under gdb, and set a breakpoint in XSetInputFocus, did the exercise described above, and gathered the stack trace (attached stack-trace.txt). You see in the stack trace that this happens purely within gtk functions up to the event loop in g_main_context_dispatch. No firefox code involved. Probably the reason why mostly this web console window does it, rather than all firefox windows might be a timing issue (event processing takes somewhat longer, so that focus is only stolen once the next application had it already, rather than immediately, while firefox still legitimately has it.)
In order to confirm that this XSetInputFocus is indeed causing the problem, I started firefox again with an LD_PRELOADable object (also attached xgrab.c) that ignores XSetInputFocus if the time parameter is CurrentTime... Indeed this fixes the issue, and also proves that XSetInputFocus is being called with this unsafe value for the time parameter. No ill side effects were observed from disabling XSetInputFocus in such a way.
I figure that gtk intends to hand off focus to one of its own sub windows when it gets focus, but as it neglects to properly use the time parameter, and as (in this case) it only gets around reacting once it has already lost focus again, it ends up stealing it back from the next application.
Proposed fix: either supply a meaningful time value (such as maybe the time the event that triggered that XSetInputFocus was received), or event better: consider whether that XSetInputFocus is needed at all (Firefox' web console seems to be doing just fine with it disabled...)