United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4490692 Lightweight component receives incorrect KeyEvents for accented keys
4490692 : Lightweight component receives incorrect KeyEvents for accented keys

Details
Type:
Bug
Submit Date:
2001-08-10
Status:
Resolved
Updated Date:
2005-06-07
Project Name:
JDK
Resolved Date:
2005-06-07
Component:
client-libs
OS:
solaris_8,linux_sun,linux
Sub-Component:
java.awt
CPU:
x86,sparc,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
6

Related Reports
Duplicate:
JDK-4780503 - IME subsystem appears to snaffling 8 bit chars on Linux
Relates:
JDK-4092016 - Solaris: lightweight components do not receive key events for an important key
Relates:
JDK-5057184 - regression: direct input of ISO-8859-2 diacriticals fail on Linux

Sub Tasks

Description
Name: boT120536			Date: 08/10/2001


java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24 mixed mode)

I use Solaris 8, CDE Window Manager and Java SDK 2 v1.3.1. The keyboard is a
Sun type 6 USB keyboard. The keyboard layout is modified through xmodmaprc as
follows (to mime Hungarian keyboard layout in order to access hunarian accented
characters via one key press (remapped pairs: a'-;, e'-', i'-`, o'-=, o:-0, o"-
[, u'-], u:--, u"-\)):
keycode 59=	0xe1	0xc1	0x27	0x22
keycode 58=	0xe9	0xc9	0x3b	0x3a
keycode 60=	0xed	0xcd	0x60	0x7e
keycode 53=	0xf3	0xd3	0x3d	0x2b
keycode 46=	0xf6	0xd6	0x30	0x29
keycode 52=	0xfc	0xdc	0x2d	0x5f
keycode 54=	0xf5	0xd5	0x5b	0x7b
keycode 56=	0xfb	0xdb	0x5c	0x7c
keycode 55=	0xfa	0xda	0x5d	0x7d
keycode 125=	0xff1b	0xff1b	0xff1b	0xff1b
keycode 48=	0xffca	0xffca	0xffca	0xffca
keycode  102 = 0xffb7
keycode  99 = 0xffb4
keycode  100 = 0xffb5
keycode  101 = 0xffb6
keycode  94 = 0xffab
keycode  92 = 0xffd7
keycode  106 = 0xffff
keycode 104=	0xffb9
keycode 103=	0xffb8
keycode 96=	0xffb1
keycode 97=	0xffb2
keycode 98=	0xffb3
keycode 105=	0xffb0
keycode 35=	0x7a	0x5a
keycode 36=	0x79	0x59
remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L
keycode 108 = NoSymbol

Though there's no problem with AWT components and the accented characters,
swing components does not receive KEY_PRESSED events for the 'accented' keys,
the key code in the events is always zero, and the key char differs in
KEY_RELEASED from that of KEY_TYPED in case of the super-ASCII unicode
characters.

The (somewhat edited) result of the test code is (P=pressed, T=typed,
R=released. The format is EventTypeKeyCode-KeyChar-(int)KeyChar). Keys pressed
are ;[=a in both cases
AWT component
P0-?-233 T0-?-233 R0-?-233
P0-?-245 T0-?-245 R0-?-245
P0-?-243 T0-?-243 R0-?-243
P65-a-97 T0-a-97 R65-a-97

Swing component
T0-?-233 R0-?-233 # missing key pressed event
T0-o-337 R0-?-245 # different (code page converted) key char in KEY_RELEASED
T0-?-243 R0-?-243
P65-a-97 T0-a-97 R65-a-97 # correct result for regular key

Listening to AWT key events provides an even weirder result... UNcomment
commented lines to experience it.

The test code follows:

import java.util.*;

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;


public class TestFrame extends JFrame
{
	public TestFrame()
	{
		addWindowListener(new ExitAdapter());
		
		TextField textField = new TextField();
		JTextField textField2 = new JTextField();
		
		getContentPane().add(textField, BorderLayout.NORTH);
		getContentPane().add(textField2, BorderLayout.SOUTH);
		
		KAdapter adapter = new KAdapter();
		textField2.addKeyListener(adapter);
		textField.addKeyListener(adapter);
	
		/*
		Toolkit.getDefaultToolkit().addAWTEventListener(adapter,
			AWTEvent.KEY_EVENT_MASK);
		*/
	}
	
	
	
	public static void main(String[] args)
	{
		TestFrame frame = new TestFrame();
			
		frame.pack();
		frame.show();
	}
	
	
	class KAdapter extends java.awt.event.KeyAdapter implements
		java.awt.event.AWTEventListener
	{
		public void eventDispatched(AWTEvent event)
		{
			/*
			System.out.print(" AWT" + event.getID() + " ");
			*/
		}
		
		public void keyTyped(java.awt.event.KeyEvent e)
		{
			key(e, 'T');
		}
		public void keyPressed(java.awt.event.KeyEvent e)
		{
			key(e, 'P');
		}
		public void keyReleased(java.awt.event.KeyEvent e)
		{
			key(e, 'R');
		}
		public void key(java.awt.event.KeyEvent e, char type)
		{
			int code = e.getKeyCode();
			char khar = e.getKeyChar();
			int charInt = (int) khar;
			System.out.print(type);
			System.out.print(code);
			System.out.print('-');
			System.out.print(khar);
			System.out.print('-');
			System.out.print(charInt);
			System.out.print(' ');
			if (type == 'R')
				System.out.println();
		}
	};
}

I have not experienced these problems on Windows 2000, Java SDK 1.3.1,
Hungarian regional settings.

Kertes Gabor
(Review ID: 129071) 
======================================================================

Name: jk109818			Date: 12/20/2001


FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.0-rc-b87)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b87, mixed mode)

FULL OPERATING SYSTEM VERSION :
SunOS 5.8 Generic_108528-01 sun4u sparc SUNW,Ultra-5_10
with French locale and French keyboard.


A DESCRIPTION OF THE PROBLEM :
KeyPressed Event is not called, when I pressed accented
characters from the French keyboard.

? 00B2 Superscript two
? 00E0 Latin small letter a with grave
? 00E7 Latin small letter c with cedilla
? 00E8 Latin small letter e with grave
? 00E9 Latin small letter e with acute
? 00F9 Latin small letter u with grave


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run the following program
2. Key in the following list to jTextField1 from French
keyboard
//exp: the keycode is displayed as well as other keys.
//act: nothing is displayed.

? 00B2 Superscript two
? 00E0 Latin small letter a with grave
? 00E7 Latin small letter c with cedilla
? 00E8 Latin small letter e with grave
? 00E9 Latin small letter e with acute
? 00F9 Latin small letter u with grave


EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected:
The appropriate keycode is displayed on the standard output,
after I key in the accented characters from French keyboard
as well as other key tops.
Actual:
//act: Following keys display nothing to the standard
output.

? 00B2 Superscript two
? 00E0 Latin small letter a with grave
? 00E7 Latin small letter c with cedilla
? 00E8 Latin small letter e with grave
? 00E9 Latin small letter e with acute
? 00F9 Latin small letter u with grave


This bug can be reproduced always.

---------- BEGIN SOURCE ----------
// Frame1.java
package frenchkeyboard;

import java.awt.*;
import javax.swing.*;
import java.awt.event.*;

public class Frame1 extends JFrame {
  JTextField jTextField1 = new JTextField();

  public Frame1() {
    try {
      jbInit();
    }
    catch(Exception e) {
      e.printStackTrace();
    }
  }
  public static void main(String[] args) {
    Frame1 frame1 = new Frame1();
    frame1.setSize(new Dimension(400,300));
    frame1.setVisible(true);
  }
  private void jbInit() throws Exception {
    jTextField1.setText("jTextField1");
    jTextField1.addKeyListener(new
java.awt.event.KeyAdapter() {
      public void keyPressed(KeyEvent e) {
        jTextField1_keyPressed(e);
      }
    });
    this.getContentPane().add(jTextField1,
BorderLayout.CENTER);
  }

  void jTextField1_keyPressed(KeyEvent e) {
    System.out.println("keyPressedKeycode:"+
e.getKeyCode());
    System.out.println("keyPressedKeychar:"+
e.getKeyChar());
  }
}

// End of Frame1.java
---------- END SOURCE ----------
(Review ID: 137590)
======================================================================
###@###.### 2004-07-29

Comments
WORK AROUND

Name: boT120536			Date: 08/10/2001


None.
There's a nice and clear article about this bug at: http://www.hta-
bi.bfh.ch/~hrm/JavaKeyEventProblem/
This bug report can be considered as a duplicate of #4092016 but it __cannot
be__ closed. It's not fixed.

(Also when using the "Click to Focus" option of CDE, after positioning the
mouse pointer outside the frame there's no way to enter accented characters,
although the non-accented input is working. Bug.)
======================================================================
2004-09-15 
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang
2004-09-15 
EVALUATION

From the submitter:

> You recently submitted a bug on this and in investigating it I have a
> question. Do you get similiar behavior for other Swing components,
> like a JButton subclass? For example, if you change your program to
> add a KeyListener to a JButton do you see the same behavior?
Same behaviour for JComponent and the following tested subclasses:
JTextField, JPanel, JButton. Both j2sdk1.3.1 and j2sdk1.4beta.
  
Just a brief reminder of the problems (Solaris 8, click to focus CDE   
environment, Metal L&F).
No KEY_PRESSED events for the accented characters when mouse pointer over
window.  
No KEY_PRESSED and KEY_TYPED events for the (ascii-range) accented
characters when mouse pointer outside of window. 
Wrong keyChar in KEY_RELEASED events for the accented characters when mouse
pointer over window.
Wrong keyChar in  KEY_PRESSED, KEY_TYPED and KEY_RELEASED events for the 
(over ascii-range) accented characters when mouse pointer outside of window.
(Wrong keyChar means code page mapped (for example 337 > 245))
No keyCode present in received KEY_PRESSED and KEY_RELEASED events for the
accented characters. 
  
j2sdk1.3.1 always provides correct results in these situations under the
Windows platform.
One additional info:
  
All the following environment variables are set to 'hu_HU.ISO8859-2':
LANG, LC_COLLATE, LC_CTYPE, LC_MONETARY, LC_NUMERIC, LC_TIME 

------
Based on this, it sounds like NO lightweight components are getting KeyEvents in this particular configuration, and thus it sounds like an awt issue.
###@###.### 2001-08-15

I'm not exactly sure why no keyPressed events are getting sent to the 
lightweight components as described.  However, the keyChar for keyPressed 
and keyReleased events is not guaranteed to be meaningful.  KeyTyped events 
are for reporting character input:  keyPressed and keyReleased events are not.  
I think this is, at its root, requests to add keycodes for the French and 
Hungarian keyboards.  

The other issue mentioned is that the keyChar for KEY_TYPED events is 
incorrect when the system is configured in a particular way, and the mouse 
pointer is outside the window.  That is a very strange result.  I thought 
I had seen something like it previously, but we were never able to track 
down what the problem was.  

###@###.### 2003-04-29


Name: osR10079			Date: 11/01/2003

I see two problems in this bugreport:
1. KEY_PRESSED is not generated for some special keys
2. KEY_TYPED has wrong key char for these keys

Here is my view of the problem:
At the begining of key event processing AWT asks input method if they want handle this event (if yes AWT do nothing).
In our case, when focus on lightweight component and user presses non-standard key, input methods want.
So, AWT does not generate any events relys on input methods.  But, for some reasons, they do not generate 
KEY PRESSED too (So, I think that the first problem is in the input methods code).
After that input methods creates InputMethodEvent (INPUT_METHOD_TEXT_CHANGED) and post it to Swing. 
And then Swing creates corresponding KEY_TYPED for this event (see JTextComponent.replaceInputMethodText()).
So, it looks like, the cause of the second problem is in Swing.

Based on eveluation I reassign this bug to IM team for further investigation.

###@###.### 2003-11-2

======================================================================

The reason that the KEY_PRESSED for those special keys are not generated is that the underlying XIM is consuming the KeyPress XEvent.  Here is the spec for XFilterEvent, which we call for input method processing:

If XFilterEvent returns True, then some input method has
filtered the event, and the client should discard the event.

And the case mentioned here definitely returns True from XFilterEvent.  In summary, Java applications should not rely that KEY_PRESSED events are always passed for each key press, since the underlying input method may consume it.  This holds true even on Windows platforms.  For example, if the user is inputting East Asian scripts, such as Chinese, Japanese, or Korean, applications may not see all the KEY_PRESSED events while the text is in composition.

As to the other aspect of this bug, i.e, KEY_TYPED has wrong key char, there is not enough information on this bug report, and so far I could not reproduce the problem, i.e., I could successfully input those accented characters in Swing text components with the provided xmodmap table.  If the problem still persists, please open another bug with a detailed information.

I am closing this bug as not a bug as the reason mentioned above.

###@###.### 2003-11-03

Further investigation revealed that XFilterEvent does not return True in this case.  Reopening the bug.

###@###.### 2003-11-03

There is a piece of code in awt_x11inputmethod_lookupString(awt_InputMethod.c)
as follows:


    switch (status) {
    case XLookupBoth:
        if (!composing) {
            if (keysym < 128 || ((keysym & 0xff00) == 0xff00)) {
                *keysymp = keysym;
                result = False;
                break;
            }
        }

I replaced that '128' with '0xff' so that it includes those accented keysyms,
and this particular problem seems to be solved.  But the problem is that the
keysym returned from this function is overridden in handleKeyevent.  In this
problem case, the keysym is overridden with the value from XKeycodeToKeysym,
which happened to be the same as the one that is returned from the IM code.
Since the keysym is generated just by the keyboard mapping, and no IM is involved.
But those accented characters can also be input with the input method. i.e.,
"Compose"+"a"+"'" generates a-acute.  In this case, even though the IM code
returns a-acute keysym correctly, it would be overridden with the one from
XKeycodeToKeysym, which would return the keysym for the last apostrophe.  So for
the "Compose" key sequence method, the keysym from the IM code should not be
overridden unconditionally.

###@###.### 2003-11-05

We decided to pull the fix for this problem from Tiger.  Please see the bug report 5057184 for more detail.  We expect a complete KeyEvent related fixes in Mustang.

###@###.### 2004-07-13

Should be fixed for XToolkit (default in Mustang) with umbrella bug 4360364.
###@###.### 2005-06-06 10:30:09 GMT
2004-07-13


Hardware and Software, Engineered to Work Together