cannot input Japanese on Android because the inputtype is password

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• s/VISIBLE_PASSWORD/NORMAL/ (androtext.diff, text/plain, 2019-08-30 01:39:42 +0000, 778 bytes)

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

Comments on the original bug report:

On 2019-08-29 08:48:23 +0000, tamo wrote:

http://hg.libsdl.org/SDL/annotate/bfed06214c2a/android-project/app/src/main/java/org/libsdl/app/SDLActivity.java#l2123

InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD doesn't allow GBoard (and probably any other keyboards) to input Japanese (or any languages except English).

This problem breaks Kivy TextInput widgets.
When I tap a text field, keyboard opens. But it restricts itself to ASCII.

Please use TYPE_TEXT_VARIATION_NORMAL or something friendly to Japanese instead.

https://developer.android.com/reference/android/text/InputType#TYPE_TEXT_VARIATION_VISIBLE_PASSWORD

On 2019-08-30 01:39:42 +0000, tamo wrote:

Created attachment 3935
s/VISIBLE_PASSWORD/NORMAL/

On 2019-08-30 06:39:48 +0000, Sylvain wrote:

For the record, this was added here:

"We found an issue where certain Android keyboards (like the S6 with
predictive text) wouldn't work ... Certain keyboards use a predictive text
mode that does not dispatch a traditional onKey events, which is troublesome
... but telling the OS to use a "visible password" keyboard helps deal with
this problem ... perhaps there's some other way (onKeyPreIme?) to do
"textediting" events, but for now, this should be a fast fix ...
I hear it affects the Galaxy Tab A 8.0", Galaxy S6, Asus ZenPhone 2, maybe
others"

https://hg.libsdl.org/SDL/rev/b98c133b5cfd

https://developer.android.com/reference/android/text/InputType.html#TYPE_NUMBER_VARIATION_NORMAL

TYPE_NUMBER_VARIATION_NORMAL is 0x00000000
TYPE_NUMBER_VARIATION_PASSWORD is 0x00000010

On 2019-08-30 15:21:37 +0000, tamo wrote:

Thanks, Sylvain. Your information is definitely what I've wanted!
(I'm afraid hg annotate doesn't tell me the history of android-project.)

Then, if you just want to suppress "suggestions" (I don't know when onKey events are emitted and when not), what about FLAG_NO_SUGGESTIONS?

https://developer.android.com/reference/android/text/InputType.html#TYPE_TEXT_FLAG_NO_SUGGESTIONS

I'd like to stress that the current implementation makes SDL's great TextInput workframe nearly useless for Asian users.

On 2019-08-31 12:01:53 +0000, Sylvain wrote:

Your patch sounds totally correct. But I can't reproduce previous bug (my keyboard hides the suggestions when It appears in SDL).
Maybe we should get the original poster in to see if that doesn't conflict.

On 2019-09-01 02:56:46 +0000, tamo wrote:

But he (Joshua Granick, aka singmajesty) and his Open FL no longer uses SDL, does he?
https://github.com/openfl/openfl/search?q=SDL&unscoped_q=SDL

I'd like to take a closer look at android-project code someday, but I'm afraid it's not today.

Maybe just dispatching onKey on text event would work?

On 2019-09-01 22:11:23 +0000, Ryan C. Gordon wrote:

I reached out to Joshua but having heard yet. I'm not against just applying this patch though, fwiw.

--ryan.

On 2019-09-06 07:43:22 +0000, tamo wrote:

(In reply to Ryan C. Gordon from comment # 6)

I'm not against just applying this patch though, fwiw.

Go ahead, please. ;)

I found an official guide (https://developer.android.com/training/keyboard-input/commands.html ) which reads:
"You should never rely on receiving key events for any key on a soft input method (an on-screen keyboard)."

It makes sense, I think -- because a key basically represents one single character, like a single-quoted char in C, while a soft input can represent a longer string, like a double-quoted string in C. They are fundamentally different things, even if the results are the same, e.g. 'S' and "S". So we should not expect that we can handle every input via onKey events. There are many kinds of input, so we have to take care of many kinds of events. Restricting the input type is not the way to go.

On 2019-10-23 09:28:26 +0000, Sylvain wrote:

I've added it in https://hg.libsdl.org/SDL/rev/6f0ec1079286

On 2019-11-28 01:19:45 +0000, Sam Lantinga wrote:

This patch broke all individual key events for the soft keyboard, so I'm reverting it and reopening this bug for investigation of a better solution.
https://hg.libsdl.org/SDL/rev/d642e14375b6

On 2019-11-28 01:21:16 +0000, Sam Lantinga wrote:

Maybe we can re-enable the patch and find another way to handle the pre-IME text that provides key events for ASCII non-composed characters?

Sylvain, can you investigate?

On 2019-11-28 09:34:56 +0000, Sylvain wrote:

Yes I can try, but please provide more information about "pre-IME text that provides key events for ASCII non-composed characters".

What keyboard ? device ? text ? SDL functions ? you use, and what do you observe good/wrong ?

[slouken]

@1bsyl, can you back out ccb1245?

The problem is that TYPE_TEXT_VARIATION_VISIBLE_PASSWORD is needed to get individual key events, but it needs to be disabled to get IME input. I think what we need to do is remove that flag and then synthesize key events from the IME input where possible. What do you think?

[1bsyl]

@slouken ok, I'll back out this commits.

I am not really a user of IME input, so I am not sure how to do that for this issue

[1bsyl]

8b1a2fe

[pytypist]

why we must get individual key events for english char?
when in android and open soft keyboard, we can think english also use input method too, because it provide some suggestion. so it combine the key as one word.(if your close the suggestion function, you can get the original individual key events for engish char)

i think 1bsyl's commit is ok.

[slouken]

I'll take a look at this for 2.0.18.

The original idea was to provide SDL scancode and keycode events as they are available on other platforms. However we definitely need IME input to work, so maybe for soft keyboards we can reverse engineer the keycodes when IME input arrives.

[slouken]

We're already doing scancode conversion for IME input text. This needs more investigation and testing, so I'm pushing it to 2.0.20.

[slouken]

Can you double check this in the latest code?
I've changed it quite a bit to allow immediate feedback on typed characters in English, and I want to make sure I haven't introduced any issues with other languages.

Thanks!