Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2]
On Thu, 21 Jan 2021 21:41:09 GMT, Dmitry Markov wrote: >> Marked as reviewed by aivanov (Reviewer). > >> 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. > > Thank you for confirmation! With the fix we have the same behaviour as you > described. Thanks, Dmitry. I tested your new fix. It's fine now on Swing and AWT. - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2]
On Thu, 21 Jan 2021 21:34:25 GMT, Alexey Ivanov wrote: >> Dmitry Markov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use endComposition() instead of endCompositionNative() > > Marked as reviewed by aivanov (Reviewer). > 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. Thank you for confirmation! With the fix we have the same behaviour as you described. - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Thu, 21 Jan 2021 21:17:53 GMT, Dmitry Markov 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
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2]
On Thu, 21 Jan 2021 13:51:58 GMT, Dmitry Markov wrote: >> Problem description: >> The IME behaviour has changed starting from recent Windows 10 builds. In >> particular if the complex characters (Japanese, Chinese, etc.) are entered >> to some component and the focus is transferred to another component (which >> does not support the IM) the IM is disabled and the unconfirmed composition >> string gets discarded. >> On previous Windows versions in the same situation the composition string is >> not discarded. >> >> Fix: >> It is necessary to take care of unconfirmed composition string once the IME >> is going to be disabled. >> >> Testing: >> All our automated regression and JCK tests passed with the proposed change. > > Dmitry Markov has updated the pull request incrementally with one additional > commit since the last revision: > > Use endComposition() instead of endCompositionNative() Marked as reviewed by aivanov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Thu, 21 Jan 2021 19:25:16 GMT, Alexey Ivanov wrote:
> 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.
-
PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Thu, 21 Jan 2021 14:54:34 GMT, Dmitry Markov 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
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Thu, 21 Jan 2021 14:18:43 GMT, Alexey Ivanov 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 https://github.com/openjdk/jdk/pull/2142#issuecomment-763340186 ) introduced by the first version of the fix. - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Thu, 21 Jan 2021 13:47:30 GMT, Dmitry Markov 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? - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Wed, 20 Jan 2021 12:28:36 GMT, Alexey Ivanov wrote: >>> > Fix: >>> > It is necessary to take care of unconfirmed composition string once the >>> > IME is going to be disabled. >>> >>> The fix commits the unconfirmed composition string. Committing is better >>> than discarding. Is it possible to preserve the >> state and to leave the string uncommitted? >> >> The fix reverts the previous (correct) behaviour back. It is unnecessary to >> store the state and keep the string. That activity may be quite complicated >> and requires additional resources especially if there are several components >> with active IME > >> > The fix commits the unconfirmed composition string. Committing is better >> > than discarding. Is it possible to preserve the >> > state and to leave the string uncommitted? >> >> The fix reverts the previous (correct) behaviour back. > > According to the bug description, it used to stay in uncommitted state. > >> It is unnecessary to store the state and keep the string. That activity may >> be quite complicated and requires additional resources especially if there >> are several components with active IME > > I definitely agree that committing the text is better behaviour than > discarding uncommitted text. > > I am for accepting these changes unless we can keep the text uncommitted and > allow the user to work with text when the focus moves back to the text > component. An interesting thing is that the test (see AWTTextTest1.java) behaves like a native application if TextField is replaced with JTextField. It appears AWT and Swing components behave differently while processing input method requests. That’s a great topic to discuss but it is out of scope for this PR. We can open a separate bug for it, if any. Going back to the current PR. I updated 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. - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2]
> Problem description: > The IME behaviour has changed starting from recent Windows 10 builds. In > particular if the complex characters (Japanese, Chinese, etc.) are entered to > some component and the focus is transferred to another component (which does > not support the IM) the IM is disabled and the unconfirmed composition string > gets discarded. > On previous Windows versions in the same situation the composition string is > not discarded. > > Fix: > It is necessary to take care of unconfirmed composition string once the IME > is going to be disabled. > > Testing: > All our automated regression and JCK tests passed with the proposed change. Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: Use endComposition() instead of endCompositionNative() - Changes: - all: https://git.openjdk.java.net/jdk/pull/2142/files - new: https://git.openjdk.java.net/jdk/pull/2142/files/1f9189bf..3d486e20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2142&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2142&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2142/head:pull/2142 PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Tue, 19 Jan 2021 13:18:22 GMT, Dmitry Markov wrote: > > The fix commits the unconfirmed composition string. Committing is better > > than discarding. Is it possible to preserve the > > state and to leave the string uncommitted? > > The fix reverts the previous (correct) behaviour back. According to the bug description, it used to stay in uncommitted state. > It is unnecessary to store the state and keep the string. That activity may > be quite complicated and requires additional resources especially if there > are several components with active IME I definitely agree that committing the text is better behaviour than discarding uncommitted text. I am for accepting these changes unless we can keep the text uncommitted and allow the user to work with text when the focus moves back to the text component. - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Wed, 20 Jan 2021 07:35:18 GMT, Ichiroh Takiguchi
wrote:
>> How do the native components work in that case like awt textarea or external
>> apps like notepad?
>
>> How do the native components work in that case like awt textarea or external
>> apps like notepad?
>
> I tested TextField+TextField, TextArea+TextArea, TextArea+TextField.
> Without fix: Preedit string was cancel by input focus change.
> With fix: Preedit string was committed into clicked component.
>
> For external application, I used Sakura Editor, because it can create 2
> editor panes on one window.
> Preedit string was committed before moving input focus.
> I tried attached testcase.
>
> ```java
> 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. Start testcase
> 2. Click upper TextField, turn on IME, type some character (In case of
> Japanese, type "aiu")
> 3. Click lower TextField, preedit string is committed into lower TextField.
>
> Without the fix, preedit string was canceled by above operation.
Hello Ichiroh,
Thank you for the details. I can reproduce it. I will look into this..
Regards,
Dmitry
-
PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Wed, 20 Jan 2021 05:43:51 GMT, Sergey Bylokhov wrote: > How do the native components work in that case like awt textarea or external > apps like notepad? I tested TextField+TextField, TextArea+TextArea, TextArea+TextField. Without fix: Preedit string was cancel by input focus change. With fix: Preedit string was committed into clicked component. For external application, I used Sakura Editor, because it can create 2 editor panes on one window. Preedit string was committed before moving input focus. - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Wed, 20 Jan 2021 05:19:15 GMT, Ichiroh Takiguchi
wrote:
>> Hello Dmitry.
>> Sorry, I should use GitHub instead of mailing list.
>> I tested your fix, I saw side effect by committing preedit string.
>> I'll give you detail information.
>
> I tried attached testcase.
> 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. Start testcase
> 2. Click upper TextField, turn on IME, type some character (In case of
> Japanese, type "aiu")
> 3. Click lower TextField, preedit string is committed into lower TextField.
>
> Without the fix, preedit string was canceled by above operation.
How do the native components work in that case like awt textarea or external
apps like notepad?
-
PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Tue, 19 Jan 2021 16:31:58 GMT, Ichiroh Takiguchi
wrote:
>>> > Fix:
>>> > It is necessary to take care of unconfirmed composition string once the
>>> > IME is going to be disabled.
>>>
>>> The fix commits the unconfirmed composition string. Committing is better
>>> than discarding. Is it possible to preserve the
>> state and to leave the string uncommitted?
>>
>> The fix reverts the previous (correct) behaviour back. It is unnecessary to
>> store the state and keep the string. That activity may be quite complicated
>> and requires additional resources especially if there are several components
>> with active IME
>
> Hello Dmitry.
> Sorry, I should use GitHub instead of mailing list.
> I tested your fix, I saw side effect by committing preedit string.
> I'll give you detail information.
I tried attached testcase.
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. Start testcase
2. Click upper TextField, turn on IME, type some character (In case of
Japanese, type "aiu")
3. Click lower TextField, preedit string is committed into lower TextField.
Without the fix, preedit string was canceled by above operation.
-
PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Tue, 19 Jan 2021 13:18:22 GMT, Dmitry Markov wrote: >>> Fix: >>> It is necessary to take care of unconfirmed composition string once the IME >>> is going to be disabled. >> >> The fix commits the unconfirmed composition string. Committing is better >> than discarding. Is it possible to preserve the state and to leave the >> string uncommitted? > >> > Fix: >> > It is necessary to take care of unconfirmed composition string once the >> > IME is going to be disabled. >> >> The fix commits the unconfirmed composition string. Committing is better >> than discarding. Is it possible to preserve the > state and to leave the string uncommitted? > > The fix reverts the previous (correct) behaviour back. It is unnecessary to > store the state and keep the string. That activity may be quite complicated > and requires additional resources especially if there are several components > with active IME Hello Dmitry. Sorry, I should use GitHub instead of mailing list. I tested your fix, I saw side effect by committing preedit string. I'll give you detail information. - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Tue, 19 Jan 2021 12:44:22 GMT, Alexey Ivanov wrote: > > Fix: > > It is necessary to take care of unconfirmed composition string once the IME > > is going to be disabled. > > The fix commits the unconfirmed composition string. Committing is better than > discarding. Is it possible to preserve the state and to leave the string uncommitted? The fix reverts the previous (correct) behaviour back. It is unnecessary to store the state and keep the string. That activity may be quite complicated and requires additional resources especially if there are several components with active IME - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
On Tue, 19 Jan 2021 11:10:35 GMT, Dmitry Markov wrote: > Fix: > It is necessary to take care of unconfirmed composition string once the IME > is going to be disabled. The fix commits the unconfirmed composition string. Committing is better than discarding. Is it possible to preserve the state and to leave the string uncommitted? - PR: https://git.openjdk.java.net/jdk/pull/2142
Re: [EXTERNAL] RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
Hi Ichiron, I have updated the bug. Now the test, steps to reproduce and other details are available. Please let me know if you need anything else. Regards, Dmitry > On 19 Jan 2021, at 11:44, Ichiroh Takiguchi > wrote: > > Hello Dmitry. > > The bugid seems to be private, so I don't know the details. > I think the current code can change the candidate string after getting the > focus. > If possible, could you show me the test instructions ? > > Thanks, > Ichiroh Takiguchi > > On 2021-01-19 20:16, Dmitry Markov wrote: >> Problem description: >> The IME behaviour has changed starting from recent Windows 10 builds. >> In particular if the complex characters (Japanese, Chinese, etc.) are >> entered to some component and the focus is transferred to another >> component (which does not support the IM) the IM is disabled and the >> unconfirmed composition string gets discarded. >> On previous Windows versions in the same situation the composition >> string is not discarded. >> Fix: >> It is necessary to take care of unconfirmed composition string once >> the IME is going to be disabled. >> Testing: >> All our automated regression and JCK tests passed with the proposed change. >> - >> Commit messages: >> - 8258805: Japanese characters not entered by mouse click on Windows 10 >> Changes: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openjdk.java.net_jdk_pull_2142_files&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=tQjpctdFBD-VNGT6Sz99HLO87e4Il0g5UPyncfk05xQ&e= >> Webrev: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__webrevs.openjdk.java.net_-3Frepo-3Djdk-26pr-3D2142-26range-3D00&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=uS7Zv56IELOfi9JydPxkC8cn11F2sm2rQIzygpVRKGU&e= >> Issue: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8258805&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=2ceq871Y2SbUmo-W1IRN4YDFPxeXMq1Y1GSY4YgkyNY&e= >> Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod >> Patch: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openjdk.java.net_jdk_pull_2142.diff&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=V5Hl37kt-btSEbTU2y1pD1-_e-z1N_QDDSl2tRIc6HI&e= >> Fetch: git fetch >> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openjdk.java.net_jdk&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=v3cOrMgmRWxELPv_w6aY_bwvvM6_qqYJY5yaIW6tADY&e= >> pull/2142/head:pull/2142 >> PR: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openjdk.java.net_jdk_pull_2142&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=XG8QFzRvrJv3WP3HW32IfaG7xG8WqxAlQkk2Fp3u708&e=
Re: [EXTERNAL] RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
Hello Dmitry. The bugid seems to be private, so I don't know the details. I think the current code can change the candidate string after getting the focus. If possible, could you show me the test instructions ? Thanks, Ichiroh Takiguchi On 2021-01-19 20:16, Dmitry Markov wrote: Problem description: The IME behaviour has changed starting from recent Windows 10 builds. In particular if the complex characters (Japanese, Chinese, etc.) are entered to some component and the focus is transferred to another component (which does not support the IM) the IM is disabled and the unconfirmed composition string gets discarded. On previous Windows versions in the same situation the composition string is not discarded. Fix: It is necessary to take care of unconfirmed composition string once the IME is going to be disabled. Testing: All our automated regression and JCK tests passed with the proposed change. - Commit messages: - 8258805: Japanese characters not entered by mouse click on Windows 10 Changes: https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openjdk.java.net_jdk_pull_2142_files&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=tQjpctdFBD-VNGT6Sz99HLO87e4Il0g5UPyncfk05xQ&e= Webrev: https://urldefense.proofpoint.com/v2/url?u=https-3A__webrevs.openjdk.java.net_-3Frepo-3Djdk-26pr-3D2142-26range-3D00&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=uS7Zv56IELOfi9JydPxkC8cn11F2sm2rQIzygpVRKGU&e= Issue: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8258805&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=2ceq871Y2SbUmo-W1IRN4YDFPxeXMq1Y1GSY4YgkyNY&e= Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openjdk.java.net_jdk_pull_2142.diff&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=V5Hl37kt-btSEbTU2y1pD1-_e-z1N_QDDSl2tRIc6HI&e= Fetch: git fetch https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openjdk.java.net_jdk&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=v3cOrMgmRWxELPv_w6aY_bwvvM6_qqYJY5yaIW6tADY&e= pull/2142/head:pull/2142 PR: https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openjdk.java.net_jdk_pull_2142&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=TWSRKjAEFvjdtcldX_CzGUCRvo92UQrQaevJPjdE9G0&m=pSPWtUQC712ERQcCWzl97FRkUYd8Rgu1S4ejmCvqfho&s=XG8QFzRvrJv3WP3HW32IfaG7xG8WqxAlQkk2Fp3u708&e=
RFR: 8258805: Japanese characters not entered by mouse click on Windows 10
Problem description: The IME behaviour has changed starting from recent Windows 10 builds. In particular if the complex characters (Japanese, Chinese, etc.) are entered to some component and the focus is transferred to another component (which does not support the IM) the IM is disabled and the unconfirmed composition string gets discarded. On previous Windows versions in the same situation the composition string is not discarded. Fix: It is necessary to take care of unconfirmed composition string once the IME is going to be disabled. Testing: All our automated regression and JCK tests passed with the proposed change. - Commit messages: - 8258805: Japanese characters not entered by mouse click on Windows 10 Changes: https://git.openjdk.java.net/jdk/pull/2142/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2142&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258805 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2142.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2142/head:pull/2142 PR: https://git.openjdk.java.net/jdk/pull/2142
