XGrabPointer focus stealing issue in firefox, stacktrace only contains gtk functions
Steps to reproduce
- Open Firefox
- Visit a page that has a password dialog (such as facebook.com) which you had already visited before
- A menu opens all by itself with suggestions of previously entered login/password combos
- Move mouse to another window: firefox still holds on its focus! You only regain control once you closed that menu manually using Esc or something else.
- Later when just moving the mouse over the firefox window, it opens up that annoying menu again, grabbing the focus and not letting go.
Current behavior
Firefox grabs the keyboard focus and doesn't let go.
Expected outcome
Menu may well open, but focus should be released when mouse moves on
Version information
3.24.5-1
Additional information
Attached are a stacktrace gdb.txt of firefox when it calls XGrabPointer. You'll see that this is being called from within gtk, and there's gtk functions all the way to the g_main_context_dispatch event loop.
Similar XGrabPointer issues have been existing for several years, and firefox is pointing its finger elsewhere (claiming that they don't call XGrabPointer directly... "I don't sere a call to XGrabKeyboard in our source so I'm not sure about the reported cause here."). One example of such a firefox bug report is here (that one was triggered by the prompt asking to save a login/password combo after entering one manually, or by the "doorhanger" menu for URL completion. That instance of the bug did actually show a couple of firefox functions in the stacktrace): https://bugzilla.mozilla.org/show_bug.cgi?id=1386699
A workaround is to use a preloadable object xgrab.c that just replaces the XGrabPointer API call with a no-op. With that object active, these login menus still open up normally, are usable, but they allow focus to move on, and close as soon as firefox loses focus.
Let's hope this is not again a third party component "making" gtk misbehave :-)