JDK-6853146 : Regression: on-the-spot input is broken in AWT Peered components
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_2.5.1,windows,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 2009-06-19
  • Updated: 2011-06-07
  • Resolved: 2011-06-07
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.
JDK 7
7 b142Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
On Windows, on-the-spot style input method input is broken in AWT TextField or TextArea classes.

How to reproduce:
1. Run some apps that have AWT text field or text area on Windows in Japanese locale
2. Give the input field a focus by clicking on it.
3. Switch the input mode from alphabet to Hiragana, by pressing ALT+'`' key.
4. Type something.  The input composition takes place on the title bar.  This should happen at the caret position in the text field/area.

Looks like this is a regression started to happen with JDK7 b55.  b54 works fine.

Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/7/6853146
28-04-2011

SUGGESTED FIX $ hg diff src/windows/native/sun/windows/awt_TextComponent.cpp diff -r b5e609488bc8 src/windows/native/sun/windows/awt_TextComponent.cpp --- a/src/windows/native/sun/windows/awt_TextComponent.cpp Tue Mar 01 15:24:46 2011 +0300 +++ b/src/windows/native/sun/windows/awt_TextComponent.cpp Thu Apr 21 20:15:52 2011 +0400 @@ -191,8 +191,11 @@ void AwtTextComponent::SetCompositionWin { HIMC hIMC = ImmGetContext(); // rc is not used for text component. - COMPOSITIONFORM cf = { CFS_POINT, {0,0}, {0,0,0,0} }; + COMPOSITIONFORM cf = { CFS_FORCE_POSITION, {0,0}, {0,0,0,0} }; GetCaretPos(&(cf.ptCurrentPos)); + // the proxy is the native focus owner and it contains the composition window + // let's convert the position to a coordinate space relative to proxy + ::MapWindowPoints(GetHWnd(), GetProxyFocusOwner(), (LPPOINT)&cf.ptCurrentPos, 1); ImmSetCompositionWindow(hIMC, &cf); LOGFONT lf;
21-04-2011

EVALUATION Starting from 6806217, top-level is the native focus owner (no the text components) and we need to convert the position of the composition window to a coordinate space relative to top-level.
21-04-2011

EVALUATION An interesting thing is that there are scenarios in which the problem becomes visible with jdk6. Frame frame = new Frame("owner"); frame.setBounds(100,100,100,100); frame.add(new TextArea()); frame.setVisible(true); Window window = new Window(frame); window.setBounds(300,300,100,100); window.add(new TextArea()); window.setVisible(true); When the user starts typing in the text area of the window, the composition window located outisde the window. In the scenario above, the invisible proxy window created by AWT is the native focus owner and the proxy redirects IME messages to the text area. The problem disappears when the text area is the native focus owner (not the proxy window).
21-01-2011

EVALUATION After the changes for 6806217, the focus proxy is used for any window (including frames) and the focus proxy started to receive some notifications that should come to an IME window. WM_IME_STARTCOMPOSITION message "This message is a notification to an IME window to open its composition window." In the testcase, this notification comes to the focus proxy but not to the text component.
23-06-2009

EVALUATION b55 involves a massive change in AWT for focus (6806217). Since the input method code has not changed in this build, I am suspecting that the AWT change may have caused this regression. Transferring this bug to the AWT team for further investigation.
19-06-2009