JDK-4780941 : After KANJI conversion with ATOK12 on TextFiled, input can't work on Solaris
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1_02,1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris
  • CPU: generic,sparc
  • Submitted: 2002-11-19
  • Updated: 2003-05-21
  • Resolved: 2002-12-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.4.1_03 03Fixed 1.4.2Fixed
Related Reports
Duplicate :  
JDK-4840551 - IMFTest failure - no prompt commit from lookup choice operation
Description
========================================================
JDK : Mantis jdk1.4.2 b07
OS  : Solaris sparc 8, 9 and 10
      Solaris x86 9
IM  : ATOK12
locale : ja_JP.euc, pck and utf8
========================================================

After converting japanese character to KANJI or KATAKANA with ATOK12,
nothing can be inputted on TextField.
It seems that focus is lost.

Cliking another window and go back to TextField which I was inputting,
an input funtion works again.

This problem does not occur with ATOK 8.

Steps to reproduce;
1. compile and run attached test case(CharView.java and FontView.java).
   % java CharView
2. Change from "Button" to "TextField".
3. Click on one of the Textfield.
4. Ctrl+SPACE
5. Type "a"
6. Push SPACE key twice so that Conversion List window comes up.
Then, you can see some "KANJI" items on the window.
7. Select one of the item lised on the window  using SPACE key
   ex. You need to push SPACE key 4 times in order to select the 4th item from a top.      
8. Hit Return key to commit it.
9. Selected character is displayed on TextField.
10. Try to input some characters.

Then, nothing can be inputted on TextField.
Cliking another window and going back to TextArea, character can be inputted.

It seems that focus does not return from Conversion List window and get lost.

* This input way is frequently used for japanese users.

* This problem is reproducible on not only TextField but also TextArea.

* This problem does not occur with ATOK 8.

* I confirmed that this problem is repoducible since mantis b03.

* I tried the same test with Hopper, but I saw another problem that selected item in step 6 avobe is not displayed on TextField.
I can't confirm if this is a regression or not.
  
* I tried the same test with Merlin, but I saw another problem that selected item in step 6 avobe is displayed and Japanese Input Mode is not available until I clicked another window and go back to the TextFiled.


[###@###.### 2002-11-19]
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_03 mantis-beta FIXED IN: 1.4.1_03 mantis-beta INTEGRATED IN: 1.4.1_03 mantis-beta VERIFIED IN: 1.4.1_03 mantis-beta
24-08-2004
EVALUATION As described in the problem text, the cause of this problem seems that the input focus does not return to the TextField correctly, after the look up panel disappears. I found that the problem is not reproducible if you move focus to another application by pressing Alt+Tab before the input method operation. i.e., between 3 and 4 in the problem text, do the following: 3a. Press Alt+Tab, then the focus goes to another Motif application. 3b. Click on the Textfield to get the focus back to CharView. So I think there may be some focus problem in the AWT. ###@###.### 2002-11-19 If this is a regression, we should try to fix this for Mantis. ###@###.### 2002-11-19 I was able to reproduce the problem on my machine (iceflow) with ATOK12 and ja_JP.PCK locale. It looks like text field that had focus lost it but didn't get focus back while in Java we still think he has focus. That's why we are unable to set it when user clicks in it with mouse and that's why when you switch to some other text field then switch back to the first one it receives focus. ###@###.### 2002-11-27 I was able to reproduce the problem with latest AWT workspace. The problem is as following: when Conversion List window comes up it generates FocusOut event for the CharView frame, after it closes it generates FocusIn event. This events look very inconvenient for us - it looks like CharView left the focus for... CharView. That introduces the problem - Java code skips this event, while native code disables focus owner on native level. Obviously, native code shouldn't do this as there will be no possibility to turn focus back. The native code responsible for this is in shellEH(awt_TopLevel.c). ###@###.### 2002-11-27
27-11-2002
SUGGESTED FIX Check that the window we are loosing focus for is actually the same window which is loosing focus and don't disable focus in this window in this case. *** /tmp/geta2880 Wed Nov 27 14:37:20 2002 --- awt_TopLevel.c Wed Nov 27 14:37:18 2002 *************** *** 1256,1262 **** // as if we didn't leave previous focusable window so Java events will generated for it. if (oppositeShell != NULL && isFocusableWindowByShell(env, oppositeShell) ! && isFocusableWindowByShell(env, w)) { // The necessary FOCUS_LOST event will be generated by DKFM. // So we need to process focus list like we received FocusOut --- 1270,1276 ---- // as if we didn't leave previous focusable window so Java events will generated for it. if (oppositeShell != NULL && isFocusableWindowByShell(env, oppositeShell) ! && isFocusableWindowByShell(env, w) && w != oppositeShell) { // The necessary FOCUS_LOST event will be generated by DKFM. // So we need to process focus list like we received FocusOut ###@###.### 2002-11-27
27-11-2002