WPF - IME Fix Korean character emitting issue

[billshinji]

Fixes [issue-number]

• (Partially) fixes WPF - IME Windows 8.1/10/11 #1262

Summary: [summary of the change and which issue is fixed here]

• I have added a small code to WpfImeKeyboardHandler.cs to address a Hangul character (Korean alphabet) is not emitting to the current input box after a Hangul is composed by IME. In other words, a user cannot make a word or a sentence using Korean IME because every time a single character is composed, it disappears and start 'composing' mode all over again.
• According to my inspection, it seems that Korean IME keeps producing characters while IME is in IME_COMPOSITION mode even before IME_ENDCOMPOSITION is sent. It is like laying eggs while a chicken is walking. Current approach to IME implemented in CefSharp.Wpf seems that in order to "finalize" composing a text, ImeSetComposition() must be first called, and then ImeFinishComposingText() must be called.
• I am not an expert to IME programming so I cannot guarantee my solution (together with CefSharp.Wpf's approach to IME implementation) is appropriate. But I am a native Korean and it works as expected while not creating any side effects to Japanese or Chinese IME. I can speak/write Japanese or Chinese a little bit, so I also tested those IMEs as well.

Changes: [specify the structures changed]

• I have modified CefSharp.Wpf.Experimental.WpfImeKeyboardHandler.cs like below:

1. add the following code:

if (languageCodeId == ImeNative.LANG_KOREAN)
{
    owner.GetBrowserHost().ImeSetComposition(text, underlines.ToArray(), new Range(int.MaxValue, int.MaxValue), new Range(compositionStart, compositionStart));
    owner.GetBrowserHost().ImeFinishComposingText(false);
}

just below the following line inside the function OnImeComposition()

owner.GetBrowserHost().ImeCommitText(text, new Range(int.MaxValue, int.MaxValue), 0);

2. move the following declarations to the top of the function (preferrably under string text = string.Empty;) in order to reference 'underlines' and 'compositionStart' in the newly-added code above:

var underlines = new List<CompositionUnderline>();
int compositionStart = 0;

I also figured out there is no side effects to Japanese or Chinese IME even if I skipped the if test (if (languageCodeId == ImeNative.LANG_KOREAN)) but I don't want to make any side effects not found during my own test. It is 'experimental' anyway and we need to improve the WPF IME problem over time.

How Has This Been Tested?

Using CefSharp.Wpf.Example.SimpleMainWindow.xaml, (and plugging in the experimental IME keyboard handler of course) I typed several Korean, Japanese, and Chinese sentences.

Windows 10.0.18363.592 (x64) - Korean, Japanese, and Chinese IME installed

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Updated documentation

Checklist:

• Tested the code(if applicable)
• Commented my code
• Changed the documentation(if applicable)
• New files have a license disclaimer
• The formatting is consistent with the project (project supports .editorconfig)

[AppVeyorBot]

✅ Build CefSharp 79.1.360-CI3434 completed (commit 74994e1d8b by @billshinji)

[amaitland]

Instead of hosting these values up, just pass in an empty array and 0 to ImeSetComposition please. Passing in values directly makes the code clearer.

Move underlines and compositionStart back to their original place.

[AppVeyorBot]

✅ Build CefSharp 79.1.360-CI3435 completed (commit b5f097effd by @billshinji)

[amaitland]

Please revert formatting change please.

[amaitland]

Please revert formatting change please.

[billshinji]

Oh the whitespaces! I see. Sorry for the inconvenience. :-)

[AppVeyorBot]

✅ Build CefSharp 79.1.360-CI3436 completed (commit d58235e339 by @billshinji)

[amaitland]

Thanks, hopefully others can test and report back.