1196777 - [GTK3] keyboard input focus sticks on a single window

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[fcheslack]

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).

Comment 1

[Karl Tomlinson (:karlt)]

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

Comment 2

[Nathan Froyd [:froydnj]]

Having the same issues.  Super annoying.

Comment 3

[Nathan Froyd [:froydnj]]

(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?

Comment 4

[Karl Tomlinson (:karlt)]

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.

Comment 5

[Stephen Eisenhauer (BHSPitMonkey)]

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.)

Comment 7

[Stephen Eisenhauer (BHSPitMonkey)]

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.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch

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 10

[Karl Tomlinson (:karlt)]

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?

Comment 11

[Martin Stránský [:stransky] (ni? me)]

(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.

Comment 12

[Karl Tomlinson (:karlt)]

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.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

(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?

Comment 14

[Karl Tomlinson (:karlt)]

(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.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

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

Comment 16

[Koala Yeung]

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

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Moving all open Keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.