JDK-6743433 : IM candidate window is not shown until window is deactivated and reactivated again
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6u10,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-09-01
  • Updated: 2011-05-18
  • Resolved: 2011-05-18
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.
6u11Fixed 7 b48Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Steps to reproduce:

1. Install Chenese (Taiwan) / Chinese (Traditional) Quick input method support
2. Run any Swing application with text area, for example, Notepad demo
3. Switch into Chinese and start typing into the text area
4. If you don't see IM candidate window while typing, the bug is reproduced
5. Deactivate window (click on the desktop)
6. Acivate window (click on the text area). Candidate window is shown

The problem is reproduced starting from 7.0-b02, so it may be related to 6359035. There is another change request about focus issues revealed by 6359035: 6542975 - but the fix for it doesn't solves this new problem with candidate window.

SUGGESTED FIX @@ -3929,7 +3936,7 @@ void AwtComponent::OpenCandidateWindow(i SetCandidateWindow(iCandType, x-rc.left, y-rc.top); } if (m_bitsCandType != 0) { - DefWindowProc(WM_IME_NOTIFY, IMN_OPENCANDIDATE, m_bitsCandType); + ::DefWindowProc(GetHWnd(), WM_IME_NOTIFY, IMN_OPENCANDIDATE, m_bitsCandType); } }

EVALUATION To open the candidate window AWT goes through the following steps: 1. the system posts the WM_IME_NOTIFY (IMN_OPENCANDIDATE) message to the AWT top level 2. AWT's subclassing procedure consumes the message (AwtComponent::WmImeNotify) 3. calculates the position of the candidate window (AwtComponent::InquireCandidatePosition) 4. tries to pass the WM_IME_NOTIFY message to the next handler by the ::DefSubclassProc call (AwtComponent::OpenCandidateWindow) 5. finally, the last handler in the subclass chain should call the original window procedure for the AWT top level. Most likely, ::DefSubclassProc fails to call ::DefWindowProc and the step 5 is missed. This happens because AWT calls ::DefSubclassProc in the context of the custom message (WM_AWT_OPENCANDIDATEWINDOW) instead of the WM_IME_NOTIFY message. The IME's handlers of the WM_IME_NOTIFY message are first hanlders in the subclass chain. So AWT doesn't need to call ::DefSubclassProc and we may directly call the original window procedure by the ::DefWindowProc call

EVALUATION Interesting that the problem is not reproducible on Windows Vista. At the same time it is reproducible on Windows XP.