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.