United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-5057184 regression: direct input of ISO-8859-2 diacriticals fail on Linux
JDK-5057184 : regression: direct input of ISO-8859-2 diacriticals fail on Linux

Details
Type:
Bug
Submit Date:
2004-06-03
Status:
Closed
Updated Date:
2004-07-28
Project Name:
JDK
Resolved Date:
2004-07-17
Component:
client-libs
OS:
linux
Sub-Component:
java.awt:i18n
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:
5.0 (b59)

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

Sub Tasks

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
WORK AROUND

use two keys combination input method (a deadkey and character) to perform input.
###@###.### 2004-06-15

                                     
2004-06-15
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
                                     
2004-07-13
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


                                     
2004-09-19



Hardware and Software, Engineered to Work Together