User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20150820004005 Steps to reproduce: Restore session with multiple windows split across multiple virtual desktops. Use Firefox normally for a short time, switching focus between multiple Firefox windows and other application windows. Actual results: From the first context switches, or within a few minutes of use, keyboard input stops being directed to the newly focused window, and instead continues to be directed to a single Firefox window as long as any Firefox window has focus. No amount of switching contexts reliably fixes it. Mouse input generally seems to still go to the correct place. It's possible this is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1170342 but I couldn't be sure. This is Kubuntu 15.04 (so Firefox running in KDE, not Gnome) in case that matters. Expected results: Keyboard input should follow window focus. It should especially not be directed to a window that is not in view, as it seems that could easily lead to security vulnerabilities (password prompt in one window but input is going somewhere else).

Does GDK_CORE_DEVICE_EVENTS=1 in the environment work around the problem?

Having the same issues. Super annoying.

(In reply to Karl Tomlinson (ni?:karlt) from comment #1) > Does GDK_CORE_DEVICE_EVENTS=1 in the environment work around the problem? I've been running with this for a week or so and it does seem to fix the problem. What does that mean we should do?

This would be the same root issue as bug 1170342. Disabling xi2 event processing in GDK is a simple way to remove the regression here, but that will also disable smooth trackpad scrolling, touch events, etc, so it would be nice to allow people to turn it back on if they are not affected by this bug. It's a bit tricky because the only simple control we have is an environment variable when opening the display, which happens early, so environment variables can be checked but I don't know whether prefs are available at that point. Perhaps the patch in bug 1170342 can be improved, but it is hard to know what to do to it without knowing what the bug is. Ideally it would be most helpful to find the root cause. I have kwin 4.11.14 here but haven't managed to reproduce with xorg-server 1.16.4. See https://bugzilla.mozilla.org/show_bug.cgi?id=1170342#c9 for where I got to. If you are able to help with any of that it would be much appreciated. If we can track this down to an x server bug, then perhaps we can just disable xi2 events until/unless running on a fixed server.

For what it's worth, I've been experiencing the same problem for a week or two in Ubuntu 15.04 and 15.10 (currently at FF 41.0.2). I discovered that certain actions can be taken as workarounds: - Creating a new window or breaking a tab into its own window will force the new window to be "it". - Merging a tab into a different window causes that window to become "it". ("It" refers to the Firefox window currently receiving all Firefox keyboard input at a given time.)

I recently discovered that, for me at least, this issue was being caused by the "unclutter" daemon. I elected to just uninstall the unclutter package from my system and it hasn't been a problem since. Other threads point out that adding the "-noevent" command-line option to unclutter also solves the problem.

It may help to ask GDK for the focus events at least :). Not sure it fixes all the issues but fixes Bug 1260902 at least.

Comment on attachment 8746507 [details] [diff] [review] patch https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-focus-in-event says "To receive this signal, the GdkWindow associated to the widget needs to enable the GDK_FOCUS_CHANGE_MASK mask." but I think that is inaccurate. What needs GDK_FOCUS_CHANGE_MASK is the toplevel window, but gtk_window_realize() provides that for us. GtkWindow then dispatches the event to its (non-toplevel) |focus_widget| via the focus-in-event signal, even when the widget has no window. I don't expect this patch to make a difference. Can you explain how it does? Is there code that checks GDK_FOCUS_CHANGE_MASK before dispatching focus-in-event?

(In reply to Karl Tomlinson (ni?:karlt) from comment #10) > https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-focus-in- > event > says "To receive this signal, the GdkWindow associated to the widget needs to > enable the GDK_FOCUS_CHANGE_MASK mask." but I think that is inaccurate. > > What needs GDK_FOCUS_CHANGE_MASK is the toplevel window, but > gtk_window_realize() provides that for us. > > GtkWindow then dispatches the event to its (non-toplevel) |focus_widget| via > the focus-in-event signal, even when the widget has no window. > > I don't expect this patch to make a difference. > Can you explain how it does? > Is there code that checks GDK_FOCUS_CHANGE_MASK before dispatching > focus-in-event? I didn't investigate that deeply. Does it hurt us by any way to set the GDK_FOCUS_CHANGE_MASK explicitly, according to the documentation? Also we use a different event widget (toplevel vs. container) if it matters here. Node that this is XI2 - the GDK_FOCUS_CHANGE_MASK makes difference only when XI2 is enabled. From a quick look I see the GDK_FOCUS_CHANGE_MASK check here for instance: https://github.com/GNOME/gtk/blob/master/gdk/x11/gdkdevice-xi2.c#L748 Anyway, I believe we have more pressing issues that debugging gdk to find if we really need the set the mask or not. Especially when Gtk doc says we need to set it I'd follow it here.

Dispatching X11 focus events directly to child windows, instead of going via the toplevel window as intended, introduces risk of confusion in the focus handling process.

(In reply to Karl Tomlinson (ni?:karlt) from comment #12) > Dispatching X11 focus events directly to child windows, instead of going > via the toplevel window as intended, introduces risk of confusion in the > focus > handling process. I don't understand - we set kEvents to mShell which is toplevel, correct? The child event container is used only for CSD. Or do I miss something?

(In reply to Martin Stránský from comment #13) > I don't understand - we set kEvents to mShell which is toplevel, correct? > The child event container is used only for CSD? Usually there is only one GdkWindow, yes. Child windows in the same container widget are sometimes used, for popup windows maybe, but they are not involved in STR of bug 1260902. However, if the only GdkWindows involved are from mShell, and GtkWindow already sets GDK_FOCUS_CHANGE_MASK on this window then there is still the question of why setting GDK_FOCUS_CHANGE_MASK again makes a difference. The proposed patch should be a no-op on toplevel windows. "xwininfo -events" can check that FocusChange is set on the toplevel. I want to understand the problem before trying to apply a no-op fix. Child nsIWidgets are still used in some cases and these should not listen to GDK_FOCUS_CHANGE_MASK because child windows should not receive native focus events. There are still reasons not to use XI2 yet, so there is no rush to fix this. https://bugs.freedesktop.org/show_bug.cgi?id=93539 is one of them.

https://bugs.freedesktop.org/show_bug.cgi?id=93539 is fixed now.

With Xorg 93539 fixed upstream and with 1.19 available to the latest distros, when will this issue be considered fixed?