It looks like it's caused by a change in Gtk+, and it only happens in the 'wayland' Gdk backend. As far as I can tell we're getting mismatched focus-in and focus-out events. For example, we'll get a single focus-in and then 2 focus-out events.

I bisected Gtk+ and it points to the following Gtk+ commit:

commit ceada4adc26868b894a0a450fe3ff80a4b4846ad
Author: Jonas Ådahl <jadahl@gmail.com>
Date:   Fri Jul 1 17:03:36 2016 +0800

    wayland: Port to xdg_shell unstable v6
    
    https://bugzilla.gnome.org/show_bug.cgi?id=769937


I tried a very simple gtk test case and couldn't immediately reproduce it. So there may be something we're doing which triggers this behavior.

How did you test when bisecting? You won't be able to run GTK+ clients prior to that commit on current GNOME. You could however test on the most recent version of weston, which should support running GTK+ clients both before and after that commit.

(In reply to Jonas Ådahl from comment #2)
> How did you test when bisecting? You won't be able to run GTK+ clients prior
> to that commit on current GNOME. You could however test on the most recent
> version of weston, which should support running GTK+ clients both before and
> after that commit.

Hmm. Well, I simply built Gtk+ and installed it into a separate prefix and then ran the spice client with LD_PRELOAD pointing to the just-built gtk and gdk libraries. I'm building and running on my Fedora 25 laptop (Gnome 3.22.2). Are you saying that this shouldn't have worked?

(In reply to Jonathon Jongsma from comment #3)
> (In reply to Jonas Ådahl from comment #2)
> > How did you test when bisecting? You won't be able to run GTK+ clients prior
> > to that commit on current GNOME. You could however test on the most recent
> > version of weston, which should support running GTK+ clients both before and
> > after that commit.
> 
> Hmm. Well, I simply built Gtk+ and installed it into a separate prefix and
> then ran the spice client with LD_PRELOAD pointing to the just-built gtk and
> gdk libraries. I'm building and running on my Fedora 25 laptop (Gnome
> 3.22.2). Are you saying that this shouldn't have worked?

I'm saying that a different backend will be used prior to that commit, if you test this under the Fedora 25 GNOME desktop. If you start "weston", and test from inside weston, you should be able test with the same GDK backend (wayland) further back in time.

(In reply to Jonas Ådahl from comment #4)
> (In reply to Jonathon Jongsma from comment #3)
> > (In reply to Jonas Ådahl from comment #2)
> > > How did you test when bisecting? You won't be able to run GTK+ clients prior
> > > to that commit on current GNOME. You could however test on the most recent
> > > version of weston, which should support running GTK+ clients both before and
> > > after that commit.
> > 
> > Hmm. Well, I simply built Gtk+ and installed it into a separate prefix and
> > then ran the spice client with LD_PRELOAD pointing to the just-built gtk and
> > gdk libraries. I'm building and running on my Fedora 25 laptop (Gnome
> > 3.22.2). Are you saying that this shouldn't have worked?
> 
> I'm saying that a different backend will be used prior to that commit, if
> you test this under the Fedora 25 GNOME desktop. If you start "weston", and
> test from inside weston, you should be able test with the same GDK backend
> (wayland) further back in time.


Hi Jonas,

Sorry for the delay, but I finally got around to bisecting gtk+ under weston as you suggested above. And I now get the following as the first bad commit:

commit de2268000d7e3eb5e84603810f9a6f971efb1072
Author: Carlos Garnacho <carlosg@gnome.org>
Date:   Wed Jun 24 17:48:18 2015 +0200

    wayland: Ensure device grabs generate crossing/focus events
    
    On X11 this is something the windowing system does for us, which the
    wayland backend should emulate, being grabs completely client-side.
    
    So, if the grab and current focus windows differ, make sure we emit
    focus/crossing events as it corresponds to the grab device.



I suspect that Gtk+ is not handling a corner case properly here, but I don't know this code well enough to determine whether that's true or not. Can you look into it a bit? Should I open a bug against Gtk+?

(In reply to Jonathon Jongsma from comment #5)
> (In reply to Jonas Ådahl from comment #4)
> > (In reply to Jonathon Jongsma from comment #3)
> > > (In reply to Jonas Ådahl from comment #2)
> > > > How did you test when bisecting? You won't be able to run GTK+ clients prior
> > > > to that commit on current GNOME. You could however test on the most recent
> > > > version of weston, which should support running GTK+ clients both before and
> > > > after that commit.
> > > 
> > > Hmm. Well, I simply built Gtk+ and installed it into a separate prefix and
> > > then ran the spice client with LD_PRELOAD pointing to the just-built gtk and
> > > gdk libraries. I'm building and running on my Fedora 25 laptop (Gnome
> > > 3.22.2). Are you saying that this shouldn't have worked?
> > 
> > I'm saying that a different backend will be used prior to that commit, if
> > you test this under the Fedora 25 GNOME desktop. If you start "weston", and
> > test from inside weston, you should be able test with the same GDK backend
> > (wayland) further back in time.
> 
> 
> Hi Jonas,
> 
> Sorry for the delay, but I finally got around to bisecting gtk+ under weston
> as you suggested above. And I now get the following as the first bad commit:
> 
> commit de2268000d7e3eb5e84603810f9a6f971efb1072
> Author: Carlos Garnacho <carlosg@gnome.org>
> Date:   Wed Jun 24 17:48:18 2015 +0200
> 
>     wayland: Ensure device grabs generate crossing/focus events
>     
>     On X11 this is something the windowing system does for us, which the
>     wayland backend should emulate, being grabs completely client-side.
>     
>     So, if the grab and current focus windows differ, make sure we emit
>     focus/crossing events as it corresponds to the grab device.
> 
> 
> 
> I suspect that Gtk+ is not handling a corner case properly here, but I don't
> know this code well enough to determine whether that's true or not. Can you
> look into it a bit? Should I open a bug against Gtk+?

CC:ing Carlos, as he might have a better idea of how this could affect other things. Either way, opening a GTK+ bug might be a good idea.

Does a single grab op produce these 2 focus out events? As we're talking about focus events, I take it this is a keyboard, where is it focused before and after the grab? inside the same window, a different window from the same client...?

I agree this probably should be tracked in a gtk+ bug (a testcase would be great too), I guess it's most probably it producing the extra focus event, but I'm unclear how.

(In reply to Carlos Garnacho Parro from comment #7)
> Does a single grab op produce these 2 focus out events? As we're talking
> about focus events, I take it this is a keyboard, where is it focused before
> and after the grab? inside the same window, a different window from the same
> client...?
> 
> I agree this probably should be tracked in a gtk+ bug (a testcase would be
> great too), I guess it's most probably it producing the extra focus event,
> but I'm unclear how.

I haven't been able to produce a minimal test case so far. For what it's worth, if you have a fedora25 machine, it can be reproduced quite easily with the stock virt-viewer. Simply connect to a guest, then click outside of the virt-viewer window to release the grab, and you will see a warning printed to the terminal. I will try to open an upstream Gtk+ bug soon.

Thanks! I'll try to reproduce with those steps

I've opened a bug in gtk+: https://bugzilla.gnome.org/show_bug.cgi?id=780422