<i18n dev> RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

[Naoto Sato]

On Thu, 21 Jan 2021 21:17:53 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>>> > > Now we will commit the composition string if there is an active client. That changes eliminates the issue described in JDK-8258805. Also the behaviour of AWTTextTest1 is the same as it used to be on the previous versions w/o the fix.
>>> > 
>>> > 
>>> > Just to confirm: the updated behaviour is similar to what was happening in previous versions of Windows 10, that is if a compositing text isn't committed, it remains uncommitted in the text component when the focus changes instead of being committed as it was the case in the previous iteration. Is my understanding correct?
>>> 
>>> I am sorry but you didn't get it right. The behaviour, which was introduced in previous iteration, is still in place. It is required to get rid of the problem described in JDK-8258805
>>> The purpose of of the second iteration is to eliminate negative side effect (more details here [#2142 (comment)](https://github.com/openjdk/jdk/pull/2142#issuecomment-763340186) ) introduced by the first version of the fix.
>> 
>> I admit I am even more confused now. To me, the description in the comment above is nearly the same as in [JBS comment](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391025). Is the difference that the original test case disabled IME for the middle JTextField whereas in the test case above all JTextField support IME?
>> 
>> In the updated version of the fix, we always commit the text on any focus change whether the newly focused component supports IME or not.
>
>> I admit I am even more confused now. To me, the description in the comment above is nearly the same as in [JBS comment](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391025). Is the difference that the original test case disabled IME for the middle JTextField whereas in the test case above all JTextField support IME?
> 
> Well.. I think the main difference between tests is that the [test attached to the bug](https://bugs.openjdk.java.net/browse/JDK-8258805?focusedCommentId=14391025&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14391025) uses `JTextField` (Swing) and the [test provided above](https://github.com/openjdk/jdk/pull/2142#issuecomment-763491615) uses `TextField` (AWT). The same input method events are processed differently for Swing and AWT text components. Good example is the following test:
> 
> import java.awt.*;
> import java.awt.event.*;
> 
> public class AWTTextTest1 extends Frame {
>     AWTTextTest1() {
>         setTitle("AWTTextTest1");
>         setLayout(new GridLayout(0, 1));
>         add(new TextField());
>         add(new TextField());
>         addWindowListener(new WindowAdapter() {
>             public void windowClosing(WindowEvent we) {
>                 System.exit(0);
>             }
>         });
>         setSize(400, 300);
>         setVisible(true);
>     }
>     public static void main(String[] args) {
>         new AWTTextTest1();
>     }
> }
> 
> 1. Run test (originally it uses `TextField`)
> 2. Click upper `TextField`, turn on IME, type some character (In case of Japanese, type "aiu") 
> 3. Click lower `TextField`, the string is canceled. 
> 4. Replace `TextField` with `JTextField` in the test. Compile and run it again.
> 5. Click upper `JTextField`, turn on IME, type some character (In case of Japanese, type "aiu")
> 6. Click lower `JTextField`, the string is committed before focus transition.
> 
>> 
>> In the updated version of the fix, we always commit the text on any focus change whether the newly focused component supports IME or not.
> 
> That’s not quite right. Actually we commit the text if the current IM client is “active client”. For example, `JTextField` is an “active client” but `TextField`  - NOT. The status “active client” depends on the implementation of getInputMethodRequests() method.

Hi,

AWT's `TextComponent` is a `peered` input client, and Swing's `JTextComponent` is an `active` input client. Thus it is OK to behave differently. I would expect that AWT's one behaves as the same as native Windows apps, and Swing's one should commit text into the component that has lost the focus.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2142