JDK-6928397 : Alt-kana/rome on JApplet/IE7 makes IME/TextField unusable
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u17
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_vista
  • CPU: x86
  • Submitted: 2010-02-22
  • Updated: 2011-03-02
  • Resolved: 2010-08-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 JDK 7
5.0u17-crev b04Fixed 5.0u29Fixed 7-poolResolved
Related Reports
Relates :  
JDK-6938377 - Successive JavaScript dialog via LiveConnect lose focus, cannot operate by keyboard
Relates :  
JDK-6978742 - RequestFocusInWindowTest test fails on WindowsXP
Description
Windows Vista, IE7 + 1.5.0_17

After starting a JApplet on IE7, moving focus to a JTextField, then enable IME.  When IME
is active, keyboard input mode can be changed between rome-character mode and kana-mode
by Alt-Kana/rome key on Japanese 106 keyboard (or screen keyboard utility).  On Vista,
this operation shows an Windows IME dialog which confirms whether user is really 
switching to the different keyboard input mode.  Select yes to change it.
 
If this was done several times while a JTextField has focus, IME/TextField becomes 
unusable.  Windows language-bar, which shows IME status disappears too.  It is shown
again while moving focus to other window on the screen.

Once this happens, if I type some keys after this problem, I see some IE7 dialog (as if the
key sequences are handled as a short-cut key) or orphaned IME dialog at the top-left
corner of the screen.  

The same operation does not show the symptom on XP.

So far, the problem does not happen with a stand-alone Swing program.
I don't see the issue with Firefox 3.5.3, Safari 4 and Chrome 4,  either.

The same symptom was seen on Vista+IE7+6u18 jre.
.
Comments
EVALUATION This fix caused the regression CR 6978742. There was another fix applied on top of the initial fix. It solved CR 6928397, CR 6938377, and CR 6978742. http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3822 All three issues are linked to ::SetFocus(NULL) call in awt_Frame.cpp. The previous fix for CR 6928397 removed that call but it caused a regression CR 6978742. To fix both these issues, ::SetFocus(NULL) call was restored, and another fix was introduced in awt_Component.cpp. But, in turn, it caused the symptomes of CR 6938377. This problem was fixed by introducing a new condition around ::SetFocus(NULL) call which excluded a set of situations when the call is not desired.
09-11-2010
SUGGESTED FIX Webrev: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3670 RTI: https://jetsvr.sfbay.sun.com:8443/BugApproval/ViewDetail.jsp?index=9964
12-08-2010
EVALUATION The following fix was suggested by Dmitry Cherepanov: http://spbweb.russia.sun.com/~dc158259/webrevs/6928397/webrev/index.html It is based on 6u18, but a similar fix is going to be used in 5.0uXX releases.
10-08-2010