New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8258805: Japanese characters not entered by mouse click on Windows 10 #2142
Conversation
👋 Welcome back dmarkov! A progress list of the required criteria for merging this PR into |
@dmarkov20 The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
Mailing list message from Ichiroh Takiguchi on i18n-dev: Hello Dmitry. The bugid seems to be private, so I don't know the details. Thanks, On 2021-01-19 20:16, Dmitry Markov wrote:
|
Mailing list message from Dmitry Markov on i18n-dev: 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,
|
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. |
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();
}
}
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? |
I tested TextField+TextField, TextArea+TextArea, TextArea+TextField. For external application, I used Sakura Editor, because it can create 2 editor panes on one window. |
Hello Ichiroh, Thank you for the details. I can reproduce it. I will look into this.. Regards, |
According to the bug description, it used to stay in uncommitted state.
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. |
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 |
I admit I am even more confused now. To me, the description in the comment above is nearly the same as in JBS comment. 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. |
Well.. I think the main difference between tests is that the test attached to the bug uses 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();
}
}
That’s not quite right. Actually we commit the text if the current IM client is “active client”. For example, |
Hi, AWT's |
@dmarkov20 This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 49 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
Thank you for confirmation! With the fix we have the same behaviour as you described. |
Thanks, Dmitry. |
/integrate |
@dmarkov20 Since your change was applied there have been 69 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 53fecba. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
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.
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/2142/head:pull/2142
$ git checkout pull/2142