bug#68914: Windows makes Emacs choke on and swallow the WIN keys

[Raffael Stocker]

I have added debug output to the keyboard hook (see the attached patch)
and was able to observe the bug while Emacs was unresponsive (either
because the current master is iffy on Windows or because of my
output...).  The locked windows key problem seems to appear when an
s-<something> combination is pressed.  Normal debug output looks like
this:

--8<---------------cut here---------------start------------->8---
KEYDOWN 0x5b, 0x5b: 0.0018 ms

Simulated S-x combination: 0.647 ms

KEYUP received, winsdown: 1, w: 0x101
no key pressed anymore, clear flags
KEYUP processed normally: 4.57 ms
--8<---------------cut here---------------end--------------->8---

Emacs first registers the windows key to be pressed in a WM_KEYDOWN
event, then upon the second call of ‘funhook’ sees the other key in the
combination and sends a WIN+<x> input to the system and then in the
third call receives the WM_KEYUP event, cleans up its state and calls
‘CallNextHookEx’ to let other applications in the hook chain process the
combination normally.  The times are the execution times of the hook.

With the bug present, I get the following output:

--8<---------------cut here---------------start------------->8---
KEYDOWN 0x5b, 0x5b: 0.0005 ms

Simulated S-x combination: 1.08 ms

0 < winsdown = 1: 0.0015 ms

0 < winsdown = 1: 0.0015 ms

0 < winsdown = 1: 0.0016 ms
--8<---------------cut here---------------end--------------->8---

The WM_KEYUP event is missing here; instead, if I press any key, Emacs
ignores it and calls ‘CallNextHookEx’ normally; the above output shows
three such key presses.  If I press ‘e’ now, Windows Explorer will
open.  That is, Emacs doesn't seem to receive the WM_KEYUP event, but
the system doesn't seem to see it either (unless my understanding of the
situation is completely wrong).

Note that the times shown above are very short; I have seen up to 15 ms,
but nothing longer.  Emacs was unresponsive for a few seconds while the
behaviour occurred; but if the hook was removed by Windows, this was not
permanent, as the remaining output shows.  Also, pressing a windows key
seems to cure the problem in this case.

I will continue to observe this and try to find out more, but any
insights are welcome.

Regards,
Raffael

funhook-debug-prints.patch
Description: funhook debug output