IME (Japanese) text input problem in StageWebView on Windows

Report · Nov 15, 2018

Our application uses the StageWebView with textarea form elements for text input, but when trying to use IME (Japanese) text input from the keyboard, the characters do not immediately appear in the textarea, as they appear in a separate IME input window, and the characters are not transferred into the textarea until the user presses the enter key.

Normal textfields (InputText) work fine, and IME is enabled (by default), so this appears to be a problem with the StageWebView class.

Does anyone know whether its possible to directly input Japanese (or Chinese etc) characters via IME on Windows ?

Report · Nov 29, 2018

Not sure if this is a BC question or not, but that is 100% standard "asian" IME input. Any Japanese person will tell you that is how you type in Japanese, there is no "direct" input because you would need a keyboard with at least 30,000 keys to support the number of standard characters you need to write day to day Japanese. Thus entering Japanese on a 109 key keyboard involves typing in multiple keys in order to "type" one Japanese character (thus you press enter)

Report · Nov 29, 2018

On Windows when you use the IME input system, a new floating toolbar appears, and you can select the language e.g. in this case Japanese, and also the "Input mode" (in this case Hiragana) and the "Conversion mode" ( where General is normally selected)

In this mode, most web browsers displaying a page with a textarea or other text input field, allow the user to directly type into the textarea, and the characters appear immediately, because the Microsoft IME converts the characters from the normal english keyboard into the Hiragana symbols.

It does this by either immediately displaying the character if there is a direct conversion , for example vowels generally get converted directly to a Japanese character.

For more complex conversions, e.g. when you type the work "kangi" , initially when you type the letter "k" it should appear in the input box on the web page, and when you subsequentially enter the "a" , this letter pair get converted into the Japanese character か

However until the user pressed the Enter key, all the characters are underlined to indicate that the conversion isn't totally complete.

Anyway, going back to the problem.

With the StageWebView, the textarea and input form elements, don't behave in the same way as in Firefox or IE or Chrome or Edge etc, because when you type a character it does not appear in the input box.

It appears in a separate floating toolbar which Windows seems to create when the target application, does not fully handle IME.

This is very confusing to users, because this floating toolbar seems to appear at random locations on the screen, i.e is not anywhere near where the user is entering the text, and most users don't notice this small toolbar and think that the AIR application is not working, as the keys they are pressing don't appear in the StageWebView

Just to confused matters, the StageWebView seems to randomly start working the same as Firefox (and Chrome etc), in that the characters do sometimes appear immediately in the textarea or input fields.

I've checked that IME is enabled, and I've tried setting the IME mode to Japanese Hiragana when the StageWebView sends a Focus_IN event, but this didn't make any difference at all.

Strangely, under some circumstances, if I hide the StageWebView by setting its stage property to null, then add another MC as a child of the current MC (I know StageWebView is independent of the normal hierarchy), then remove the MC and show the StageWebView

This usually seems to cause the IME input to work correctly. But this isn't a usable workaround to get the text to enter correctly

Report · Nov 29, 2018

I know the floating text box you are talking about, it usually comes up when you type something that does not allow input. For example if you started typing while on the desktop that floating bar would come up. So this sounds like a focus issue perhaps. I'm assuming if you type english there are no problems and if you cut n paste Japanese there are no problems?

Could you take a screenshot? I actually have Japanese windows installed so could test for you.

Also I am assuming this is an action script question and not an Adobe Business Catalyst question? I'll move the topic if that is the case, but still happy to help.

Report · Nov 29, 2018

We're using Adobe Flash (and more recently Adobe Animate) to produce a cross platform application, (Windows exe, Mac App and iPad App) using Adobe AIR

The problem is with the Windows version, (the Mac and iPad versions operate in a completely different way, so don't have this problem)

I posted this to the Adobe Developer forum, as I wasn't sure the best place to post it.

I also logged it in the Adobe Bug Tracker, but have not had any useful replies.

In this screengrab, I've moved the IME control floating toolbar onto the Windows exe's title bar so it can be seen, and I've moved the key entry floating toolbar to near the first text input box on the html page inside the Air application.

I typed "kang"

The text box just below the bullet point labelled "1. お金をためて日本に行きます。" is active

In this next screengrab, its occasionally possible to get the StageWebView to input the characters directly into the text input / textarea field

See the text that I have input onto the second text input box, and as you can see the letters are the same as before "kang"

The floating text input toolbar is not present in this case as Windows and the StageWebView are allowing direct entry of the text, including the underlining system to indicate the text has not been fulled entered until I press the Enter key

I'm still trying to work out a way to repeatably get the StageWebView to directly accept the text that is typed

It seems to happen, if I set the StageWebView stage property to null, and add a child screen to this whole screen, then remove the child screen (MC), and then set the StageWebView stage to the stage again, to show the webview.

I have tried just hiding and showing the webview, but setting stage to null , wait a few frames and set it back to the stage, but that doesn't work.

So potentially its something in the child MC that I'm loading in, which is causing Windows to handle things correctly

Also, I don't know if its related, but I intermittently get this error from the StageWebView

*** Security Sandbox Violation ***

SecurityDomain 'about:blank' tried to access incompatible context 'app:/VSL_courseApp.swf'

This can occur sometimes when the Tab key is pressed, when a textarea or form input box is selected.

However I think this is a different bug in StageWebView, as the webview is displaying a page when this warning is generated.

Report · Nov 29, 2018

Doing some more tests...

When the StageWebView IME input appears in the StageWebView input fields, it has an undesired side effect, because its no longer possible to delete any text in the input field.

Neither the Backspace or delete buttons work anymore.

i.e Even selecting existing text and pressing the delete key does not remove the text.

When this starts happening, the output window in Flash / Animate starts to show security sandbox errors as if the StageWebView has a page "about:blank" loaded (which it clearly hasn't)

I've tested Firefox and Chrome, and the delete and backspace and tab keys all function correctly when IME mode is enabled.

Report · Nov 30, 2018

Move to Adobe AIR section, I just don't personally know enough about Air.

What happens if you don't use the IME toolbar and use a keyboard combo to change the language? Maybe with the IME bar active flash is thinking the focus is wrong?

Report · Nov 30, 2018

I'm not sure what you mean about using the "keyboard combo"

I've tried enabling IME and setting the conversion etc from AS3 and it has the effect of configuring the Windows IME toolbar.

However it still does not allow text entry directly into the input field in the HTML form in the StageWebView.

I'm still trying to track down, precisely what simple sequence of events cause the input to be switched to inside the webview.

We have a complex system, where the AIR application runs its own internal webserver (on port 8080) and the StageWebServer loads pages from the webserver, and the StageWebView communicates with the application by using javascript:functionName(some_args) to pass data to the StageWebView and the StageWebView sends data back to the AIR application by sending POSTs of JSON data.

We hide and show the webview, when other "screens" are displayed in front of the screen in the screengrabs, and under some circumstances when we show the webview and reload the HTML page, the IME works inside the stagewebview

Unfortunately I can't determine precisely what sequence of events cause what results.