We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 884

Summary: SDL Text Input causes focus wars with multiple windows
Product: SDL Reporter: Alistair Lowe <alistair.lowe>
Component: eventsAssignee: Sam Lantinga <slouken>
Status: RESOLVED ABANDONED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2 CC: alistair.lowe, gzjjgod, icculus, zoucaiwangchina
Version: HG 2.0Keywords: target-2.0.0
Hardware: x86_64   
OS: Windows 7   

Description Alistair Lowe 2009-11-15 06:54:22 UTC 
With more than one window open and SDL Text Input enabled, there is a spam of SDL_WINDOWEVENT_FOCUS_GAINED between the windows, choking the event queue and confusing any user code that handles this event (in my case leads to rapid flickering between windows).

I believe this is more of an issue because SDL Text Input is enabled by default and would therefore trouble and confuse users without an obvious cause. I believe on top of a bug fix that SDL Text Input should be disabled by default, as it only requires one command to activate.

Many thanks.
Comment 1 Jiang Jiang 2010-01-19 00:24:47 UTC 
It seems SDL_TEXTINPUT event is enabled by default without invoking SDL_StartTextInput(), that looks odd to me too.

However, I failed to see why this is causing the trouble you described, especially for Windows platform, perhaps you can provide a minimum sample which can expose this issue? Thanks.
Comment 2 Sam Lantinga 2013-05-21 01:09:46 UTC 
Can you submit a test program to help reproduce this issue?

Thanks!
Comment 3 Ryan C. Gordon 2013-07-12 22:15:46 UTC 
(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 2.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.
Comment 4 Ryan C. Gordon 2013-07-27 01:03:06 UTC 
*** Bug 1482 has been marked as a duplicate of this bug. ***
Comment 5 Ryan C. Gordon 2013-07-27 01:03:50 UTC 
Bug #1482 has a reproduction case for this and some other research. I have not tried it to see if the bug still exists.

--ryan.
Comment 6 Ryan C. Gordon 2018-08-06 21:20:18 UTC 
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.