Characters typed in terminal go to TWO terminal windows

[Loïc Minier]

Hi,

This is crazy. I'm running an up-to-date hardy and when I type in a xterm window which has focus while another one is below the mouse pointer, BOTH windows receive the key presses.

Steps to reproduce:
- open two terms (tested with xterm and gnome-terminal)
- move your mouse over one of the term and make sure it gets focus
- alt-tab into the other terminal to switch focus, but leave the mouse on top of the first
- hold down a key such as "a" ("aaaaa")

This is scaring me to death.

I'm using metacity and tried disabling the "Focus follows mouse" option, but it didn't help.

Bye,

[David Nusinow (dnusinow)]

Created an attachment (id=12376)
xorg.conf

[David Nusinow (dnusinow)]

Created an attachment (id=12377)
Logfile

[Michel-tungstengraphics (michel-tungstengraphics)]

It seems to affect just repeated key events here - they get delivered to the focused window and the one below the pointer (so repeat speed appears to double when they coincide). Daniel Stone asked me to try

http://people.freedesktop.org/~daniels/no-core-xkb-actions.diff

but it makes the server abort with FatalError("Impossible keyboard event") on repeated key events.

[David Nusinow (dnusinow)]

(In reply to comment #3)
> It seems to affect just repeated key events here - they get delivered to the
> focused window and the one below the pointer (so repeat speed appears to double
> when they coincide). Daniel Stone asked me to try
>
> http://people.freedesktop.org/~daniels/no-core-xkb-actions.diff
>
> but it makes the server abort with FatalError("Impossible keyboard event") on
> repeated key events.

Yes, I get the exact same results. The bug only happens with repeated key events, and the patch causes the same crash for me.

[Peter Hutterer (peter-hutterer)]

*** Bug 13210 has been marked as a duplicate of this bug. ***

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=12490)
send correct events on autorepeat

The reason for this is a bit complicated, here's an attempt of an explanation.
XI devices have separate focus settings to core devices. A WM that sets the focus using XSetInputFocus only sets it for the core keyboard, not for all the XI devices.

In the autorepeat handler, we'd send down a core KeyPress/KeyRelease event for the device registered. This would be alternating the core keyboard and the actual device that generated the event. The former is all nice and goes to the right window, the latter however is by default set to PointerRootWin. So when the event is processed, it goes to the sprite window, causing the repeats to occur in a second window.

The solution is fairly simple: the XI device shouldn't actually generate the core event in the first place. So in the repeat handler, we check for the type of the device and create KeyPress or DeviceKeyPress accordingly. That means that XI events are still delivered to the sprite window but that's how the server has always behaved (and nobody cares about XI events anyway).

[Loïc Minier (lool)]

Hi,

This is crazy. I'm running an up-to-date hardy and when I type in a xterm window which has focus while another one is below the mouse pointer, BOTH windows receive the key presses.

Steps to reproduce:
- open two terms (tested with xterm and gnome-terminal)
- move your mouse over one of the term and make sure it gets focus
- alt-tab into the other terminal to switch focus, but leave the mouse on top of the first
- hold down a key such as "a" ("aaaaa")

This is scaring me to death.

I'm using metacity and tried disabling the "Focus follows mouse" option, but it didn't help.

Bye,

[Łukasz Krotowski (lukasz-krotowski)]

(In reply to comment #6)
> Created an attachment (id=12490) [details]
> send correct events on autorepeat

Patch fixes the bug for me, thx.

[Anders Kaseorg (andersk)]

This is scaring you to death? I found it hilarious!

[Loïc Minier (lool)]

(I find it scary due to the number of things I could accidentally leak in an IRC window such as GPG or SSH passphrases.)

Got some words from Timo Aaltonen on #ubuntu-devel:
12:29 < tepsipakki> lool: that should be fixed upstream now, and hopefully
          xserver-1.4.1 final is out later this week

If a workaround is possible, I'd love to hear about it.

[Timo Aaltonen (tjaalton)]

There is a patch upstream, not yet committed but apparently fixes this issue.

[Peter Hutterer (peter-hutterer)]

*** Bug 13223 has been marked as a duplicate of this bug. ***

[Daniel Stone (daniels)]

I was hoping to avoid the core keyboard generating repeat events at all, but this is a good minimal fix for 1.4.x. Applied with some minor cleanups -- thanks.

[Daniel Stone (daniels)]

*** Bug 13320 has been marked as a duplicate of this bug. ***

[Timo Aaltonen (tjaalton)]

The latest xorg-server in hardy should fix this, please test.

[Emilio Pozuelo Monfort (pochu)]

I can't reproduce this with 2:1.4.1~git20071119-1ubuntu1 and Hardy up-to-date.