I think this is intended behavior.

Sam, reopen this bug if you think it should change.

I added a printf() to the test code where we call SDL_CreateWindow(), in src/test/SDL_test_common.c:

printf("New window %d %s input focus\n", (int) SDL_GetWindowID(state->windows[i]), (SDL_GetWindowFlags(state->windows[i]) & SDL_WINDOW_INPUT_FOCUS) ? "HAS" : "DOES NOT HAVE");

And then rebuilt and ran testwm2 --info all:

New window 2 DOES NOT HAVE input focus
SDL EVENT: Window 2 shown
SDL EVENT: Window 2 moved to 641,388
Window 2 moved to 641,388 (display play 23")
SDL EVENT: Window 2 exposed
SDL EVENT: Window 2 gained keyboard focus

...so creating the window doesn't mark it as having input focus until it's on the screen and the event loop has run (because that's what decides when a window gets focus).

This _is_ slightly murky...I wouldn't be surprised if Windows or Cocoa makes a different promise, but I'm not sure SDL made any promise at all about the finer details of this point...the window gets focus automatically, it just has to wait until the OS says so.

--ryan.

Created attachment 1387 [details]
test program

Looks like I didn't explain the problem correctly.  I'm running an event loop.  I'm getting keyboard input events.  I'm not getting SDL_WINDOWEVENT_FOCUS_GAINED events, and SDL_GetWindowFlags() does not include SDL_WINDOW_INPUT_FOCUS even as I am processing keyboard events.

I have traced the problem to SDL_GetWindowSurface.  If I call this function right after creating my window, I never receive my initial SDL_WINDOWEVENT_FOCUS_GAINED event.  If I don't call this function, I receive the event.  I could, of course, delay calling SDL_GetWindowSurface until after I receive the SDL_WINDOWEVENT_FOCUS_GAINED event, but that seems like a rather clumsy workaround for what is clearly a bug.

Created attachment 1773 [details]
Patch to fix the bug.

The patch fixes the issue by calling SDL_PumpEvents at the end of SDL_CreateWindow, thereby preventing the events from being lost.  It doesn't really address the root cause of this issue (which I still haven't been able to track down), but it works and it shouldn't break anything.

Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!