I just encountered this issue as well. I get a KEYDOWN event for the tab key when alt+tabbing quickly even though I pressed tab while another window was focused. The KEYDOWN event reports no modifier keys when this happens. I'm running X11 on Linux (using KDE plasma + kwin)

I can confirm that this is happening on Linux in SDL 2.0.22, in particular when alt-tabbing into the app, but releasing alt first. The moment you release alt but keep holding tab, a tab key down event is produced by sdl. You can tell using this example program that this is not a repeated key press, as the first printed event has the repeat field set to 0, while subsequent events have it set to 1 if you keep holding tab.

Non SDL programs on Linux don't have this behavior, tab keys only register after a short while when the key repeat kicks in.

#include <stdio.h>
#include "SDL.h"

int main() {
  SDL_Init(SDL_INIT_EVENTS | SDL_INIT_VIDEO);
  SDL_CreateWindow("Tab test", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
  SDL_Event ev;
  while (1) {
    SDL_PollEvent(&ev);
    if (ev.type == SDL_KEYDOWN && ev.key.keysym.sym == SDLK_TAB)
      printf("TAB!!! %d\n", int(ev.key.repeat));
  }
}

I'm not sure this is a bug; I get the same results as you for your test app:

TAB!!! 0
TAB!!! 1
TAB!!! 1
TAB!!! 1
TAB!!! 1
TAB!!! 1
TAB!!! 1
TAB!!! 1
TAB!!! 1

But if I try this with, say, gedit, the cursor reacts as if I'm holding down TAB the same way.

If the concern is that the first event is a 0 even though, strictly speaking, this is already a repeating key, I'd argue that changing this would be detrimental to apps that might expect the first keydown event to be zero, and the 1 is just there to say "SDL already sent one keydown, the rest are repeat events where the key is still held down."

(This was on Gnome/x11 on Ubuntu 22.04. I need to check KDE for the other reported issue.)

The non-repeating event is registered when TAB isn't actually pressed, only held, and alt is released, this is clearly a bug. I made a text editor using SDL and when alt-tabbing into it I get bogus tabs inserted. There isn't any workaround as far as I can tell, because the app can't know this was an alt-tab, the alt modifier isn't even set.

this is clearly a bug

I don't know what to tell you...if I am running Gnome, and alt-tab to a different app, letting go of alt and continuing to hold down tab:

• gedit thinks I'm holding down tab and inserts a bunch of indentations.
• Terminal thinks I'm holding down tab and starts beeping, trying to autocomplete.
• Firefox thinks I'm holding down tab and starts bouncing between clickable HTML elements.
• Steam thinks I'm holding down tab and scrolls through every game in the storefront page.
• Discord thinks I'm holding down tab and pops up a message to tell me there are more efficient keyboard shortcuts!

SDL reports the first SDL_KEYDOWN event it sends is not a repeat event because this isn't reporting the operating system's key repeat state, it's reporting whether it's previously told you this key was down since it was pressed. It's meant to be used to tell apps that want to just know if a key is down at all (like, pressing 'W' to walk forward in Doom or Quake) that they can ignore it as an extraneous event.

Please let me know if I'm wildly misunderstanding the situation, in which case I will happily reopen this issue, but this all appears to be working as intended.

It might be working as intended on your machine, but I see a noticeable difference between other apps and my SDL app. In other apps I need to keep holding tab for another half a second or more before the app registers it. In the SDL app the key press is registered immediately when I release alt, no matter how quickly I release tab afterwards. As a proof that there is a difference in behavior see this gif in which I'm alt-tabbing between my SDL app and gedit, using the exact same key sequence, notice that the SDL app on the left, which is also a text editor, is registering tabs, while gedit isn't. You can also check that the demo I posted above has the same behavior.

What window manager is this .gif using?

I wasn't able to reproduce this in GNOME or fvwm, both of which require you to release both the alt and tab keys in order to focus on another application.

I was able to reproduce this in KDE, which will let you focus a different application while the tab key is held down if you time it and press and release the alt and tab keys just right. However this happens for other applications as well, e.g. alt-tabbing this way to Konsole will send a rapid series of tabs immediately upon it gaining focus.

Given that we don't know what window manager is reproducing this exact behavior and it doesn't happen by default on GNOME and KDE, let's go ahead and bump this to the next milestone.

I'm using Xfwm4.

I just tried this in xfwm4 in an xfce session, and it has the same behavior as KDE. When you alt-tab, the next window to receive focus gets highlighted, if you hold down tab it will cycle potential windows quickly, when you release tab, the highlighted window gets focus. You can carefully release alt and the currently highlighted window also gets focus with the tab key still down, but I tried with gedit and it got a rapid sequence of tabs as well.

It seems like normal alt-tab behavior is fine (hold alt, hold tab, highlight window, release tab, release alt), is that what you're seeing?

When I try with the checkkeys test program, here is the event sequence for a single alt-tab away and back:

INFO: Initial state: modifiers: (none)
INFO: EDIT Text (): ""
INFO: Key pressed :  scancode 226 = Left Alt, keycode 0x400000E2 = Left Alt  modifiers: LALT
INFO: Key released:  scancode 226 = Left Alt, keycode 0x400000E2 = Left Alt  modifiers: (none)
INFO: EDIT Text (): ""
INFO: EDIT Text (): ""
INFO: EDIT Text (): ""
INFO: EDIT Text (): ""
INFO: EDIT Text (): ""
INFO: EDIT Text (): ""

The normal alt-tab behavior as you described is fine, but when doing it fast I sometimes release alt first, and that's when I get the bogus tab event. Of course you'll get multiple tabs inserted in any app if you keep holding tab, but if you release both alt and tab (in that order) really fast, non-sdl apps won't register tabs, while an sdl app will.

Btw, I just tried in KDE and also ran into this undesired behavior.