This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.14
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2009-01-01 04:24:39 +0000, Joni Orponen wrote:

As the summary says, when you ALT-TAB to gain focus of a window of an SDL app on a Windows platform, ALT gets stuck until the window of the SDL app loses focus and gains focus via means not involving holding down the ALT key.

This greatly degrades the usability of SDL apps for multi tasking on Windows.

On 2009-09-13 16:33:25 +0000, Ryan C. Gordon wrote:

Tagging this bug with "target-1.2.14" so we can try to resolve it for SDL 1.2.14.

Please note that we may choose to resolve it as WONTFIX. This tag is largely so we have a comprehensive wishlist of bugs to examine for 1.2.14 (and so we can close bugs that we'll never fix, rather than have them live forever in Bugzilla).

--ryan.

On 2009-09-26 23:35:09 +0000, Sam Lantinga wrote:

Are you still seeing this with the latest SDL snapshot?
http://www.libsdl.org/tmp/SDL-1.2.zip

I modified testwm to show key events, and this was the output:
Title was set to: Testing 1.. 2.. 3...
Running in windowed mode
Key pressed: 308-left alt modifiers: LALT
App lost input focus
Key released: 308-left alt modifiers: (none)
App gained active input focus
App has been restored
Key pressed: 97-a modifiers: (none)
Key released: 97-a modifiers: (none)
Key pressed: 27-escape modifiers: (none)
Posting internal quit request
Handling internal quit request
Bye bye..
App lost input focus
Key released: 27-escape modifiers: (none)

Am I missing a step?

On 2009-09-27 11:51:25 +0000, Joni Orponen wrote:

(In reply to comment # 2)

Am I missing a step?

I'm not seeing this on Windows 7. This could be specific XP and older revisions of Windows.

On 2009-09-27 15:44:16 +0000, Sam Lantinga wrote:

It might also be fixed with the SDL 1.2 snapshot. Can you see if it's an issue on the platform for which you originally reported the bug?

On 2009-09-27 23:05:03 +0000, Joni Orponen wrote:

(In reply to comment # 4)

It might also be fixed with the SDL 1.2 snapshot. Can you see if it's an issue
on the platform for which you originally reported the bug?

Unfortunately I no longer have access to XP at home.

At the time of reporting the bug, it was manifesting at least in both Battle for Wesnoth (http://wesnoth.org/ and The Mana World (http://themanaworld.org).

Both projects deemed this an issue with SDL.

On 2009-09-28 00:06:39 +0000, Sam Lantinga wrote:

Bryan, can you test this on Windows XP? I'll guide you through the process, just give me a call whenever you're ready.

On 2009-10-02 15:38:49 +0000, Joni Orponen wrote:

(In reply to comment # 5)

(In reply to comment # 4)

It might also be fixed with the SDL 1.2 snapshot. Can you see if it's an issue
on the platform for which you originally reported the bug?

Unfortunately I no longer have access to XP at home.

At the time of reporting the bug, it was manifesting at least in both Battle
for Wesnoth (http://wesnoth.org/ and The Mana World (http://themanaworld.org).

Both projects deemed this an issue with SDL.

I just managed to replicate it again on Windows 7 RC with The Mana World.

I was in-game chatting to a lot of people in a developer meeting and actively alt-tabbing between windows. Then I noticed pressing s making me sit and stand, trying to make a question mark output a smiley and all the number keys to output smileys: alt was apparently stuck.

Some relation could come from my keyboard layout using alt gr for some characters (more commonly known as the "right alt"). FI layout.

So far this also seems to be apparent in Battle for Wesnoth and Toribash. It has never occurred to me in a non-SDL application.

I'll test again later with the latest snapshot.

On 2009-10-03 03:10:48 +0000, Sam Lantinga wrote:

Do you ALT-tab with the right alt key?

On 2009-10-03 08:06:44 +0000, Joni Orponen wrote:

(In reply to comment # 8)

Do you ALT-tab with the right alt key?

No.

I thought it could be relevant due to using the right alt key often just before and right after alt-tabbing into or out of the window.

It seems to associate with rapid typing combined with rapid window switching.

On 2009-10-03 09:19:05 +0000, Sam Lantinga wrote:

I wonder if this has something to do with character composition and switching tasks?

Can you reproduce it by alt-tabbing while composing a character with alt-gr? Both in and out?

On 2009-10-10 11:55:26 +0000, Edgar Simo wrote:

I'm also seeing this on Linux x86_64 with Fluxbox as the WM. I can reproduce both with SDL 1.2.13 and SDL 1.3 (latest SVN). Also have gotten bug reports to NAEV from users who also mention this issue with Windows.

On 2010-02-08 05:59:24 +0000, John Glista wrote:

This bug does not just happen when alt-tabbing. I believe it has something to do with the alt key itself. When playing Wolf4SDL, traditionally the alt key is used to strafe. I noticed that using the alt key causes other keys to become "stuck", or at least that is the illusion. Sometimes initiating the alt key can cause a delayed press of the ctrl key, which causes the weapon to fire. Once I changed the keyboard setup to strafe with the "/" key instead of alt, the problem was completely gone. This may have something to do with the fact that the alt key in windows transfers control to the menu bar of most applications. If we can find a way to disable this, I think the problem would be solved.

On 2010-02-24 08:20:57 +0000, Joni Orponen wrote:

(In reply to comment # 12)

This bug does not just happen when alt-tabbing. I believe it has something to
do with the alt key itself. When playing Wolf4SDL, traditionally the alt key
is used to strafe. I noticed that using the alt key causes other keys to
become "stuck", or at least that is the illusion. Sometimes initiating the alt
key can cause a delayed press of the ctrl key, which causes the weapon to fire.
Once I changed the keyboard setup to strafe with the "/" key instead of alt,
the problem was completely gone. This may have something to do with the fact
that the alt key in windows transfers control to the menu bar of most
applications. If we can find a way to disable this, I think the problem would
be solved.

I've yet to see any other keys besides ALT to get stuck or misbehave in any scenario. CTRL is a key you would notice getting stuck or pressed accidentally while playing TMW (it's the attack key).

Does alt also get stuck in Wolf4SDL when alt-tabbing or is your issue unrelated and you should probably hence report it separately?

Still happens with Windows 7 (non-RC, the real thing this time) and SDL 1.2.14.

I'm rather astonished that this has also manifests itself on Fluxbox: could be something more general than a simple mishandling of WinAPI.

By the statements here, it seems like it is quite a widespread problem. Any SDL dev able to reproduce? Please do try with mentioned applications to verify the existance of this. It could also be that the vast majority of SDL applications out there are misusing SDL and this could be avoided if the root source of this is discovered.

On 2010-06-03 10:29:34 +0000, Joni Orponen wrote:

I've just managed to reproduce this in an out of the box fresh Ubuntu 10.04 install on an old Pentium III 750MHz.

My best guess is it appears to have something to do with ALT-TABbing between windows too fast for something to catch up. This is seriously degrading usability of most of the SDL apps I use (The Mana World http://themanaworld.org/ , ManaSource http://manasource.org/ , Battle for Wesnoth http://wesnoth.org/ and Toribash http://www.toribash.com/ ). ALT is a meaningful moderation key in a lot of SDL applications.

On 2011-01-07 13:23:12 +0000, Nathaniel J Fries wrote:

Verified.
Also verified that the same happens with CTRL, SHIFT, and the Windows/Apple key.

My recommendation is to clear the mod state whenever window focus is lost.

On 2011-09-01 00:36:13 +0000, Ryan C. Gordon wrote:

Spent some time on this. Sam didn't see the bug because he was looking at the wrong thing (you do indeed get an ALT keydown/keyup combo as you should when leaving the window).

The problem seems to be that when returning back to the window, SDL calls its WIN_GetKeyboardState() function (src/video/wincommon/SDL_sysevents.c), which calls GetKeyboardState(), which gives wrong information about the state of the ALT key. I don't know why. We end up setting the keyboard mod state and the element in the SDL_GetKeyState() array, but we never get a KEYUP event from Windows to toggle them back off. The app will see the stuck key with SDL_GetModState() and SDL_GetKeyState(), but it won't get an SDL_KEYDOWN event for it, let alone the matching SDL_KEYUP.

The simplest fix seems to be just to remove WIN_GetKeyboardState(), as the keyboard is already IN the right state, and the win32 GetKeyboardState() call only tells you what the keyboard looks like in relation to your event queue anyhow, so it's nothing we wouldn't get from our usual event handler, which already maintains an array of keyboard states.

My totally untested guess is that this function was needed to workaround a Win95 bug or something. On Win7, it seems to work if you remove this.

There may be other ramifications to removing this code, though, so I don't know.

I suspect we should really just send KEYUP events for any pressed keys when keyboard focus is lost for any reason, and reset the mod state to 0, and just ignore the real keyups if they come later.

--ryan.

On 2011-09-01 00:38:33 +0000, Ryan C. Gordon wrote:

(In reply to comment # 11)

I'm also seeing this on Linux x86_64 with Fluxbox as the WM. I can reproduce
both with SDL 1.2.13 and SDL 1.3 (latest SVN). Also have gotten bug reports to
NAEV from users who also mention this issue with Windows.

The bug I'm talking about is Windows-specific, but it's possible that other platforms have similar issues in different locations in the code.

--ryan.

On 2011-09-01 01:01:45 +0000, Ryan C. Gordon wrote:

(In reply to comment # 16)

I suspect we should really just send KEYUP events for any pressed keys when
keyboard focus is lost for any reason, and reset the mod state to 0, and just
ignore the real keyups if they come later.

(Sorry for the reply spam.)

Turns out we do this already, which is why we get KEYUP events for ALT, even though win32's GetKeyboardState() thinks ALT is still pressed (because it is, as far as our win32 event queue is concerned. The KEYUP the app gets is generated by SDL, not by Windows).

So the correct fix here is to remove WIN_GetKeyboardState(), I think, and leave everything else as it is. We could get fancy with GetAsyncKeyState(), but I don't think we should. Just let all the keys default back to unpressed and call it a day.

--ryan.

On 2011-09-01 13:03:47 +0000, Ryan C. Gordon wrote:

Just tried this on Windows 95, under VMWare.

The existing code works on Win95, so I suppose some behaviour changed in the win32 API over the years.

I'm don't think we care a great deal about Windows 95, even for the 1.2 branch, but disabling the function doesn't even seem to cause Win95 any problems. So I'll remove this soon, unless anyone has an objection.

--ryan.

On 2011-09-08 22:00:44 +0000, Ryan C. Gordon wrote:

Ok, hearing no complaints, and on the basis that Gaslamp Games says their Dungeons of Dredmor players stopped complaining when they shipped this change, I put it in revision control.

Fixed in hg changeset 090d764c56e4.

--ryan.