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.

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?

(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.

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?

(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.

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

(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.

Do you ALT-tab with the right alt key?

(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.

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?

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.

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.

(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.

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.

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.

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.

(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.

(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.

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.

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.