Might be rather a problem in kglobalaccel - if you assign the alt+tab shortcut to something different (eg. showin krunner) and apply your "Press Alt+Tab and release it very quickly™" pattern, does that trigger krunner reliably?

> Alexander Potashev 
Do you use a multilayout keyboard and/or some input mapper (xim, fctix, etc..) for cyrillic input?

The window only shows if you have alt pressed for more than 90 msec. So if you do a quick alt+Tab the window is not supposed to show. Is that maybe the case for you?

any information on the questions in comment #1 and comment #2 which could help us?

I also experience this problem with Plasma 5.9.4. I tried disabling/modifying various desktop effects, reducing or increasing animation speed, as well as using the compact application switcher. 

When the application switcher fails, the Alt+Tab command seems to be registered.  The current window briefly loses focus, but it is re-focused after a short delay instead of switching to the previous window. 

I can kind of reliably reproduce the issue using xdotool, to rule out keyboard or keypress timing issues:

for i in {1..10}; do echo 'Switching...'; xdotool key 'alt+Tab'; sleep 1; done

Usually this works as expected, toggling between the konsole window and the previously selected window, but sometimes the same window gets focused multiple times. I used several applications as the previous window (Dolphin, Firefox, VS Code, ...), but couldn't notice a pattern. Is there any debug output that could help diagnose the problem?

You could run kwin from a konsole and watch the debug output.

The only two lines kwin logs when switching windows with the script from my previous comment are (after enabling debug options as described in https://github.com/lxde/lxqt/issues/836#issuecomment-144931359):

kwin_tabbox: areKeySymXsDepressed:  any of  2
kwin_tabbox: 0 : keySymX=0x "ffe9"  i= 8  mask=0x "1"  keymap[i]=0x "1"


_Sometimes_ the last number is "0" instead of "1", as in:

kwin_tabbox: areKeySymXsDepressed:  any of  2
kwin_tabbox: 0 : keySymX=0x "ffe9"  i= 8  mask=0x "1"  keymap[i]=0x "0"

However, there doesn't seem to be a direct link between the issue and this change in output (sometimes switching fails when it printed "0" before, sometimes when it printed "1").

Adding some debug statements to kwin pointed me towards grabXKeyboard in utils.cpp. Whenever Alt-Tabbing fails, this method returned false because XCB returns XCB_GRAB_STATUS_ALREADY_GRABBED instead of XCB_GRAB_STATUS_SUCCESS.

"xdotool key XF86LogGrabInfo" lists only kwin and kglobalaccel5 grabs, so maybe some race condition with the KDE hotkey handling? Unfortunately the XCB response does not seem to include any other information that may lead to the client that is actually holding the keyboard lock (which I assume is not kwin itself, as it correctly seems to release the keyboard grab).

Maybe fixed by https://phabricator.kde.org/D13128 ?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Could not reproduce lately, might be indeed fixed. May be it was only reproducible on machines of really poor performance.

Seems to have been fixed (my HW didn't change).