JDK-5057184 : regression: direct input of ISO-8859-2 diacriticals fail on Linux
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt:i18n
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2004-06-03
  • Updated: 2004-07-28
  • Resolved: 2004-07-17
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
5.0 b59Fixed
Related Reports
Duplicate :  
JDK-5056432 - REGRESSION: Can't type some non-ASCII characters with Slovenian keyboard
Relates :  
JDK-5014911 - b32c, b40, b42 input Arabic and Hebrew charaters fail in JTextComponents
Relates :  
JDK-4490692 - Lightweight component receives incorrect KeyEvents for accented keys
Relates :  
JDK-6225595 - Czech keyboard doesn't work well on Linux
Relates :  
JDK-4960727 - xkb (X Keyboard Extension) support should be fixed in XAWT.
Description
Regression: YES (from 1.4.2_04 fcs)
Package: J2SE, JRE
Version: 1.5.0-b51
Locale: cs_CZ, pl_PL, hu_HU, fi_FI

Description:
  The Czech keyboard has two ways how to insert some local characters - 
    - directly (one key) 
    - two keys combination (a deadkey and character). 
  For example \u0159 (r caron) could be inserted by key '5' 
  or by combination of key '+' and 'r'. 
 
  Direct method fails on some characters (type nothing). You can insert
  the character by the two keys combination only (drag&drop works fine too).

  It happens on the characters:
    'e caron' (\u011b), 's caron' (\u0161), 'c caron' (\u010d), 
    'r caron' (\u0159), 'z caron' (\u017e) and 'u ring above' (\u016f) 
  others characters work fine ('y acute', 'e acute', ....)

  Other applications (gnome-terminal, ..) and JDK 1.4.2_04 work fine.
  Solaris version of Tiger b51 works fine too.

Configuration(s): 
 1) SuSE Linux 8.2 (i586)
    `uname -a`: Linux d-eprg05-76-238 2.4.20-4GB #1 Mon Mar 17 17:54:44 UTC 2003 i686 unknown unknown GNU/Linux
 2) RedHat AS3.0
  
Test Suite(s):  SwingSet2.jar, AcTest.java (attached)

Reproduce Step(s): 
  - install the OS and java
  - switch to language and keyboard to Czech (by 'yast2' on SuSE, )
  - restart computer
  - run 'java -jar SwingSet2.jar' 
  - press '5' on alphanumeric keyboard 
    -> insert nothing to java application 
    (try the key on gnome-terminal for example ...)

Reproducible in previous releases(s)? 
  no in 1.4.2_04 fcs 


###@###.### 2004-06-30

Same problem reported by a CAP member:

this time I finished development migration under Linux and discovered
VERY SERIOUS BUG, which disqualify client java applications under
Linux in non-US locales (or non-Latin1 - i cannot tell exactly).

This bug appears only in current builds of JDK 1.5, not in
JDK 1.4.2.

Bug description:
  Under Linux with language set to Czech, there is no possible
  to enter some national characters in Swing text fields. Eclipse
  which uses SWT components works correctly.

  Atached screenschots with the same application after pressing
  the same sequnce of keys under 1.4.2 and Tiger Beta2.
  Screenshot with Tiger shows that some characters are missing

Operating System:
  Fedora Core 2
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-rc FIXED IN: tiger-rc INTEGRATED IN: tiger-b59 tiger-rc VERIFIED IN: tiger-rc
19-09-2004
EVALUATION I changed priority to p2/s2 because it's a regression from previous release (1.4.2_04) ###@###.### 2004-06-09 =============================================================== Duplicated on JDS B07 Cinnabar. ###@###.### 2004-06-16 ============================================================= French keyboard works fine - both ways (direct & two keys combination). Polish keyboard has the same problem like Czech but with a small modification - two keys combination works fine, direct key insert a square (=undef char). JDK1.4.2_04 works fine. (tested on RedHat AS3.0, i586) ###@###.### 2004-06-17 =============================================================== Not reproducible on Windows XP Pro. Apparently only affects Linux distros. ###@###.### 2004-06-17 ==================================================== Hungary, Slovak and Finish keyboards are affected too. The bug affects only diacriticals from ISO-8859-2 codepage that isn't in ISO-8859-1 codepage (probably all). ###@###.### 2004-06-18 ====================================== Simple KeyEvent test seems to indicate that no KeyEvents are generated for the problem keys. ###@###.### 2004-06-18 ====================================== b18,b25 and b28 works fine in Czech, b29,b30,b33,b51 and b55 fails. ###@###.### 2004-06-21 ======================================== Linked to putback for 4490652 fix? ###@###.### 2004-06-21 ======================================== I looked at the bug and it was actually caused by the fix for 4490692 (plus 4959241). The original code in awt_InputMethod.c#awt_x11inputmethod_lookupString() was: --- switch (status) { case XLookupBoth: if (!composing) { if (keysym < 128 || ((keysym & 0xff00) == 0xff00)) { *keysymp = keysym; result = False; break; } } --- This code assumes that the (keysym < 128) keys are not generated by the input method, and let the caller of this function (handleKeyEvents) generate KEY_PRESSED/TYPED/RELEASED events. But in case of accented keys, the keysym for those are >128, so they have always been handled as input method generated keys. This means that INPUT_METHOD_TEXT_CHANGED event is generated for these, and no KEY_PRESSED/TYPED/RELEASED events are generated. Bug 4490692 manifests this problem, which requires KEY_* events for the accented keys. So I modified the above code to the following: --- switch (status) { case XLookupBoth: if (!composing) { if (event->keycode != 0) { // This keysym is not generated by the input method. *keysymp = keysym; result = False; break; } } --- This means that if the input method does not generate the keysym, let the caller generate the KEY_* events. This worked fine with ISO-8859-1 accented characters, such as a-acute in French, but does not work with accented characters in ISO-8859-2 (or other ISO-8859-*), since the caller (handleKeyEvent in canvas.c/XWindow.c) only generates KEY_TYPED events for keysym < 256. This is the reason why ISO-8859-2 accented characters cannot be input from b29 build. ###@###.### 2004-06-21 We have evaluated the following three options for what to do with the bug in Tiger time frame: 1. Provide the complete fix - This would require rewriting the whole portion of AWT KeyEvent generation code. Considering where we are at Tiger product schedule. This is not an option. 2. Revert the fix for 4490692 - This may solve the bug 5057184, but it reveals the problem in 4490692, which affects all the Latin-1 countries. We consider this as bigger impact than that of 5057184, as they are in Tier-1 category, whereas Czech, Polish are in Tier-2, and Hungarian is in Tier-3. Also, reverting the fix for 4490692 invalidates all the tests we have done since b29. 3. Let it go for Tiger and provide the complete fix in the later release - Considering the above options, we concluded that this is the most viable option at this point. Also, I am transferring this bug to the AWT, as it is responsible for generating KeyEvent for those accented keys through X keymaps. ###@###.### 2004-06-24 We have decided to back out the fix for 4490692, as we have seen a lot of customers complain about this bug. I will change the status of the bug 4490692 to CPK and transfer it to the AWT, expecting the complete fix in Mustang. ###@###.### 2004-07-13 verified on SuSE 8.2 with b59. Czech and Polish keyboard works fine. ###@###.### 2004-07-26
13-07-2004
WORK AROUND use two keys combination input method (a deadkey and character) to perform input. ###@###.### 2004-06-15
15-06-2004