When the focused window changes to an xwayland window as a result of some key-combination on a client, that window receives key press events for every key that is down. This is because Xwayland handles wl_keyboard.enter as if all the keys in the array were pressed (http://cgit.freedesktop.org/xorg/xserver/tree/hw/xwayland/xwayland-input.c#n380).

This leads to various problems:

- If I press Ctrl-n to open a new chromium window, the new window gains focus and receives Ctrl-n, opening a new window. This repeats, and I end up with ~5 new chromium window depending on how quickly I was able to release the key.

- If I press Ctrl-w on a chromium window, that window closes and the next one gains focus and receives Ctrl-w. Again, this repeats and it ends up closing ~5 windows (or, until a non-chromium window is focused). This same behavior happens when exiting a terminal with Ctrl-d.

I think this problem is not as noticeable on weston because it waits for an animation to run before focusing the next window.

I checked the behavior in Xorg, and there are no additional KeyPress events on the newly focused window. Instead, the client gets the KeymapNotify event, and is able to update its keyboard state from that.

I think instead of queuing keyboard events on wl_keyboard.enter and wl_keyboard.leave, Xwayland should just directly update the state of the keyboard. I attempted to make a patch myself using set_key_{down,up}, but ran into problems when changing focus between wayland and xwayland windows. Maybe someone with more knowledge about the X input layer can do a better job.