JDK-6801620 : JPasswordField broken on JDK 6
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: beta2,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2009-02-05
  • Updated: 2011-01-24
  • Resolved: 2009-03-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 6 JDK 7
6u14 b03Fixed 7Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
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 It is the fix for 6680988 which eliminate this problem in JDK7. In JDK6 we need another, less risky, solution or workaround.
12-02-2009

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.
09-02-2009

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.
06-02-2009

WORK AROUND Use Motif toolkit.
06-02-2009

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