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

[Alexey Ivanov]

On Thu, 21 Jan 2021 14:54:34 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?
>
>> > 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 https://github.com/openjdk/jdk/pull/2142#issuecomment-763340186 ) introduced by the first version of the fix.

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

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

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