alt-tab into LÖVE window sometimes emits 'tab' keypress event

[Kartik Agaram]

Here's a simple .love file. I'll also paste in all of main.lua:

Code: Select all

Text = ''

function love.draw()
  love.graphics.setColor(1,1,1)
  love.graphics.print(Text)
end

function love.keypressed(key, scancode, isrepeat)
  if key == 'tab' then
    Text = Text..key
  elseif key == 'escape' then
    Text = ''
  end
end

As you can see, all it should do is print something out when you press tab, and clear all prints when you press escape.

Open it up, hit tab a few times. See that it works as expected.
Switch back and forth between this window and one other one using alt-tab.

Expected result: nothing is printed as you alt-tab back and forth.
Observed result: on Linux I see 'tab' print some of the time when I alt-tab quickly. If I alt-tab slowly (i.e. press alt and hold, press tab and release, see the LÖVE thumbnail focused in the switcher, release alt to switch to the window) everything works as expected. However if I switch so quickly that the switcher doesn't have time to show up, I see 'tab' printed some of the time.

I'm curious if others are able to reproduce this behavior, and on other platforms besides Linux.

I suspect (based on printing out keypressed and keyreleased events) that this is happening because when I switch windows I'm sometimes letting go of the 'alt' before the 'tab'. If that's true it seems a bit surprising since releasing one key ('alt') is creating a keypress event for a different one ('tab').

Any thoughts or workarounds most appreciated.

[MrFariator]

On Windows I don't see the perceived issue; it's working as intended regardless how fast or slow I am with my keystrokes. So long alt is pressed first and held, alt+tabbing (whether in or out of the love window) doesn't incur an additional "tab" to be printed on the screen. As such, I think this might be a more OS-specific quirk, which may or may not have an easy fix.

To work around this, perhaps you could try using the love.focus callback? Basically, make the game not process any inputs for a game tick or two when window focus is regained.

[Kartik Agaram]

Thank you! I'll try that suggestion.

[BrotSagtMist]

That one annoys me too.
Havnt had the mood to look into it tho.
Interestingly enough löve is the only program affected.

[pgimeno]

I have a similar issue when changing desktops with the keyboard; I use Super + 1 through Super + 9 as the keys to select a specific desktop; when Löve is in desktop 1 and I press Super + 1 to go back from another desktop, a "1" gets typed. For me it happens in more applications, not just Löve (maybe the ones using SDL2?). MAME and OpenMSX are affected, for example.

[BrotSagtMist]

A few keyboard problems i have in löve, namely keys not getting send, are general SDL bugs. Maybe that too is one of its general wonkynes.
But looking at the dumped events i fail to grasp whats going on here actually:

Code: Select all

focus	true	nil	nil	nil	nil	nil
keypressed	tab	tab	false	nil	nil	nil
keyreleased	tab	tab	nil	nil	nil	nil

The WM gives focus on key release for me, how we can see that release after it gained focus beats me. Let alone that we even get the keydown which actually starts the focus switch so it cannot happen after the focus switch.
The only way i can imagine that happen is that SDL is not event driven but instead does constant polling and that we actually see the result of a timeframe and not a single event.

As for solution, we need to break the event processing loop whenever the focus event appears i guess.