Hi, I suggest to check the Swing component first because they have more priority, so the swing test will be useful. A few notes about the fix: - Can you please double check that the cases described in JDK-8148555, JDK-8132503,JDK-8073008,JDK-8068283 still works as expected. We had some regressions here so it will be useful to double check. - Its possible to tweak the test a little bit, and use CountDownLatch instead of Thread.sleep + interrupt()+TimerTask +Timer. Just await() the main method and countDown() then the user press the button. In this case you can move all logic from time to the main method. I guess this will simplify the test. - Note that in case of swing you will need to call validateInput() on EDT.
> > As the term "Special character" was ambiguous, I have renamed the test case > and the appropriate comments and also removed some swing dependencies. > Updated Webrev : http://cr.openjdk.java.net/~rpatil/8180370/webrev.02/ > > Also, I have written the test case for the AWT component (TextField) only. > Is it required to write a duplicate test case for the equivalent swing > component (JTextField) ? > > Regards, > Sreeprakash > > -----Original Message----- > From: Phil Race > Sent: Saturday, June 3, 2017 2:29 AM > To: Sreeprakash Sreedharan <sreeprakas...@oracle.com>; > awt-dev@openjdk.java.net > Subject: Re: <AWT Dev> [10] Review request for JDK-8180370: Characters are > skipped on input of Korean text on OS X > > OK .. although I think this may need bake time before being backported. > but since I suppose hardly anyone is using or testing 10 at the moment that > is going to be tricky. > > -phil. > > On 06/02/2017 01:47 PM, Sreeprakash Sreedharan wrote: >> Thanks for the inputs Phil. >> >> I have updated the code and the comments. >> >> Updated Webrev : http://cr.openjdk.java.net/~rpatil/8180370/webrev.01/ >> >> The issue was that any non-alpha character(numbers and symbols) typed >> immediately after a Korean character was getting skipped. >> The non-alpha character will come if you type again. >> For example, an exclamation mark (!) entered after the Korean character for >> q will not show up. >> However, if you type it again it will appear. But instead of having 2 >> exclamation marks we have just one. >> >> I had tested it out with 2-Set Korean, Wubi Xing (Chinese) and ABC - >> Extended keyboard layouts on mac with different input methods . >> >> I had run all the manual and automatic regression tests for all text based >> controls in awt (like TextField, TextArea etc) and swing (like JTextField, >> JTextArea, JTextPane, JEditorPane etc) and did not find any issues. >> >> Thanks, >> Sreeprakash >> >> >> From: Phil Race >> Sent: Friday, June 2, 2017 9:44 PM >> To: Sreeprakash Sreedharan <sreeprakas...@oracle.com>; >> awt-dev@openjdk.java.net >> Subject: Re: <AWT Dev> [10] Review request for JDK-8180370: Characters >> are skipped on input of Korean text on OS X >> >> I am not familiar with this code but I have a few comments anyway >> >> 1. I dislike cluttering the source with bug ids. If we did that for every fix >> quite soon the source code would be a mess of semi-random numbers. >> Anyone who really wants to know when this change was made has the >> history >> >> 2. if is not a function. So "if(" -> "if (" >> >> 3. When a marked text -> When marked text >> >> 4. "!" is not a "special character" .. its quite ordinary .. so what do you >> mean ? >> >> 5. What testing have you done to make sure no other cases are broken by this >> change ? >> The new test is manual and I'd bet that most tests that might cover this >> are manual >> I'd expect to hear that you have tested different input scenarios such >> as a couple >> of input methods/locales, and AWT and Swing input with a representative >> set of >> input as well as running all the relevant regression tests. >> >> -phil. >> On 06/02/2017 07:48 AM, Sreeprakash Sreedharan wrote: >> Hi All, >> >> Kindly review the fix for JDK10. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8180370 >> Webrev: http://cr.openjdk.java.net/~rpatil/8180370/webrev.00/ >> Issue: Special characters (like !,/\<> ) were getting skipped when >> immediately entered after a marked text on MacOSX. >> Fix: Made sure that fKeyEventsNeeded flag is reset, when a non-marked text >> is encountered, so that it doesn't get ignored by key down. >> >> Note: Since the keyboard layout has to be changed to Korean, I have added a >> manual test case wherein the user is prompted to change to Korean keyboard >> layout and then execute the test. >> >> >> Regards, >> Sreeprakash >
