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
|
Java