United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6801620 JPasswordField broken on JDK 6
JDK-6801620 : JPasswordField broken on JDK 6

Details
Type:
Bug
Submit Date:
2009-02-05
Status:
Resolved
Updated Date:
2011-01-24
Project Name:
JDK
Resolved Date:
2009-03-07
Component:
client-libs
OS:
linux,generic
Sub-Component:
java.awt
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
beta2,6
Fixed Versions:
6u14 (b03)

Related Reports
Backport:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
Unable to type certain characters into a JPasswordField

Affected J2SE version:
======================
J2SE 6.0 from final to J2SE 6.0 Update 12

Affected Operating Systems:
===========================
Linux (all tested Distributions incl. RedHat and SuSE Linux)
Solaris 8, Solaris 9, Solaris 10

Error Description:
==================
Characters using the "mode shift" modifier can not be typed into
JTextComponents that are not input method enabled.

Typing e.g. "@" (\u0x40, At-sign) or "?" (\u0x20ac, Euro sign) on a
german keyboard where these characters are accessed using Alt-GR-q (@)
and Alt-GR-e into a JPasswordField yields "q" or "e" instead of "@"
and "?".

This behaviour can be reproduced with ordinary JTextFields after calling
enableInputMethods(false) on the JTextField.

This behaviour is a regression from J2SE 5 where the above scenario
worked fine.

Reproduction:
=============
A test case is included in KeyboardTest.jar.

java -jar KeyboardTest.jar

Type into password field on top of the window.  In the field below the
type text is mirrored (we use the same document to just display the
text).
In the text are below we output the received key events.

Example Log (typing "@@@"):
===========================
============================================================
Operating system: Linux, 2.6.18.8-0.13-default
Java VM version : 1.6.0_12
System locale   : de_DE
Default encoding: UTF8
============================================================
Event type    : KEY_PRESSED
Event key code: 65406
Event key text: Alt Gr
Event key char: "?" - 0xffff
============================================================
Event type    : KEY_PRESSED
Event key code: 81
Event key text: Q
Event key char: "q" - 0x71
============================================================
Event type    : KEY_TYPED
Event key code: 0
Event key text: Unknown keyCode: 0x0
Event key char: "q" - 0x71
============================================================
Event type    : KEY_RELEASED
Event key code: 81
Event key text: Q
Event key char: "q" - 0x71
============================================================
Event type    : KEY_PRESSED
Event key code: 81
Event key text: Q
Event key char: "q" - 0x71
============================================================
Event type    : KEY_TYPED
Event key code: 0
Event key text: Unknown keyCode: 0x0
Event key char: "q" - 0x71
============================================================
Event type    : KEY_RELEASED
Event key code: 81
Event key text: Q
Event key char: "q" - 0x71
============================================================
Hi all,

Any updates on this one? The customer is expecting a fix, and I'd appreciate any information that we could share with them.

Thanks,
MS

                                    

Comments
EVALUATION

Yuriko had this bug, it seems to me?
                                     
2009-02-05
WORK AROUND

Use Motif toolkit.
                                     
2009-02-06
EVALUATION

The reason of this regression is that there is no corresponding part in XAWT, which calls XtTranslateKeycode() in canvas.c of Motif Toolkit.  XKeysym.convertKeysym() should have the equivalent capability that converts, e.g., keysym for 'e' to Euro character code if AltGr is pressed on a German keyboard.
                                     
2009-02-06
EVALUATION

Oops, yes. It will be fixed in jdk7: I already have a webrev of a fix and a draft CCC related to this. Code will be (finally) XKB-enabled, will call XkbTranslateKeycode and will not have this bug. (around b47 or 48 I suppose, as soon as I'll get all approvals).

However it seems rather risky to backport all this to 6.0.
                                     
2009-02-09
EVALUATION

It is the fix for 6680988 which eliminate this problem in JDK7. In JDK6 we need another, less risky, solution or workaround.
                                     
2009-02-12



Hardware and Software, Engineered to Work Together