This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.0
Reported for operating system, platform: Android (All), All

Comments on the original bug report:

On 2012-11-11 03:57:47 +0000, Philipp Wiesemann wrote:

Hello,

SDL does not always message back closing of the screen keyboard on Android. Therefore SDL_IsTextInputActive() returns SDL_TRUE even if no keyboard is visible which means that TextInput events are still active (not needed then), a useful toggle can not be implemented (can not be sure if shown or not) and the DummyEdit still consumes events (because it was not removed).

This happens if the keyboard is closed using the BACK button on the device instead of SDL_StopTextInput() from program itself. Maybe there are also other ways to close the keyboard implicitly which cause the same problem.

The main cause for this problem is that the keyboard is handled asynchronous on Android (see Bug 1564) and the actual state is only kept inside its framework while SDL assumes it has the correct state. A solution could be if some event from Java side would call SDL_StopTextInput() if the keyboard is closed too.

On 2013-07-12 18:52:45 +0000, Ryan C. Gordon wrote:

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

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.

On 2013-07-27 09:08:13 +0000, Gabriel Jacobo wrote:

Philipp, what do you think of using the first solution here: http://stackoverflow.com/questions/7634346/keyboard-hide-event ?

On 2013-07-27 11:04:18 +0000, Philipp Wiesemann wrote:

(In reply to comment # 2)

Philipp, what do you think of using the first solution here:
http://stackoverflow.com/questions/7634346/keyboard-hide-event ?

(I assume your idea is to message SDL if onKeyPreIme() is called with BACK but still let the key close the screen keyboard.)

I have not tested this but it could be a solution for the case where a single BACK would close the screen keyboard. IMO is is no nice solution but better than no solution at all.

If an IME would exist which needs multiple BACK to close and all go through onKeyPreIme() the solution would not work there.

Additional info: For me the screen keyboard also closes if I press HOME and then return (but not if just switching using the recent applications menu). This is another case which may need to be handled later (like all the cases we do not know yet :).

On 2013-07-31 13:16:39 +0000, Gabriel Jacobo wrote:

It seems the issue at hand may be harder to solve than previously anticipated. The reason behind this is that, by design, it's not possible to tell if the soft keyboard is up.

Dianne Hackborn from Android states it here: https://groups.google.com/forum/#!topic/android-platform/FyjybyM0wGA

It's hard to believe, but devs have been resorting to a layout change event trick to determine if the keyboard is up, which we can't currently take advantage of (I tried, but we use the AbsoluteLayout, probably because we don't want our OpenGL based view moving or changing sizes...I think, and this means that our view isn't measurably affected by the keyboard coming up). Monitoring via onKeyPreIme (such as when pressing the back button) may work, but as you said there's a ton of combinations to consider, as we would be doing what is essentially a OS task.

I also tried monitoring the focus change events on the DummyEdit widget, this doesn't seem to work either.

Anyway, suggestions welcome.

On 2013-07-31 15:03:05 +0000, Gabriel Jacobo wrote:

Just to document my descent into madness...

If we show the keyboard with:

imm.showSoftInput(mTextEdit, InputMethodManager.SHOW_FORCED);

and add a:

mSurface.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@OverRide
public void onGlobalLayout() {

You get that event every time the keyboard pop up and down (and then some). If in that function you do:

imm.hideSoftInputFromWindow(mTextEdit.getWindowToken(), InputMethodManager.HIDE_NOT_ALWAYS, result)

That returns true or false, what those values mean is anyones guess (it's not documented). I was thinking that if the keyboard was showing, result will be called with RESULT_UNCHANGED_HIDDEN, and if it's shown it would be RESULT_UNCHANGED_SHOWN or something else, but this isn't the case either. Incredibly, if you try to do a "test hiding" (sort of a quantum experiment where a measurement disturbs the experiment itself), the confirmation that the keyboard is still shown is that...nothing happens

Anyway, I think giving LinearLayout or RelativeLayout (instead of AbsoluteLayout) a go and doing like everybody else does it may be the only way to solve this (silly as it may seem!).

On 2013-08-01 23:48:17 +0000, Ryan C. Gordon wrote:

(In reply to comment # 5)

Anyway, I think giving LinearLayout or RelativeLayout (instead of
AbsoluteLayout) a go and doing like everybody else does it may be the only
way to solve this (silly as it may seem!).

If we go this way, we should pull the target-2.0.0 tag and do this for 2.1...sounds like a risky change at this point.

How hard would wiring up the onKeyPreIme() check be? If it covers most of the use-cases, but will definitely fail in more complicated cases, it's still better than where we are now.

--ryan.

On 2013-08-02 11:40:59 +0000, Gabriel Jacobo wrote:

A temporary fix based on the back key detection is here: http://hg.libsdl.org/SDL/rev/d2bc997ef5d6

It seems to work on my Nexus 4, when I press HOME or use the task switch button the keyboards goes away, but it comes back when i return to my app. I'm removing the target-2.0.0 keyword but I'll keep this open so we can solve it properly (or as good as Android lets us).

On 2013-11-06 14:33:35 +0000, Gabriel Jacobo wrote:

Filed the enhancement under # 2211.