Bug ID: JDK-4159610 Menu accelerator gets inserted into text

Type: Bug
Component: client-libs
Sub-Component: java.awt
Affected Version: 1.1.6,1.2.0

Priority: P3
Status: Resolved
Resolution: Fixed
OS:
generic,solaris_2.5.1,solaris_2.6,windows_95,windows_nt generic,solaris_2.5.1,solaris_2.6,windows_95,windows_nt
CPU: generic,x86,sparc

Submitted: 1998-07-22
Updated: 1999-11-23
Resolved: 1999-06-18

Other	Other
1.2.2_002 b02Fixed	1.3.0Fixed

If I add an acceleraor (like alt+n) to a menu entry, and if the current input
focus in a JTextArea, and if I type the alt+n key sequence then *both* the accelerator is activated and an "n" gets inserted into the text.  What appears to be happening is that when alt+n is typed both a KeyPressed and a KeyTyped
event get sent.  KeyPressed activates the menu action correctly.  The KeyTyped
event is supposed to be ignored by the TextArea, but it appears not to be.
The same thing happens with meta, but not with ctrl.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel FIXED IN: 1.2.2-002 kestrel-beta INTEGRATED IN: 1.2.2-002 kestrel-beta
14-06-2004
SUGGESTED FIX Here are the diffs for the windows fix: svdiffs 1.225 1.226 awt_Component.cpp 2066,2068c2066,2068 < // If InputMethod is disabled or character is control code, < // KeyTyped Event is generated. Otherwise, InputMethod Event is < // generated. --- > // If InputMethods are disabled or the character is a control code > // or the result of a WM_SYSCHAR, a KeyTyped Event is generated. > // Otherwise, InputMethod Event is generated. 2070,2072c2070,2071 < < // Enter key generates \r in windows, but \n is required in java < if (unicodeChar == VK_RETURN) --- > if (unicodeChar == VK_RETURN) { > // Enter key generates \r in windows, but \n is required in java 2073a2073 > } svdiffs 1.226 1.227 awt_Component.cpp 2069c2069 < if (m_useNativeCompWindow \|\| unicodeChar <= 0x001F) { --- > if (m_useNativeCompWindow \|\| unicodeChar <= 0x001F \|\| system) {
11-06-2004
EVALUATION I can reproduce this with both JDK1.1.6 and 1.2 on Solaris, with the current build. I'm taking a look at it -- strange that there should be a regression like this... georges.saab@Eng 1998-07-29 There are currently some problems with KeyEvents at the native level that are rather difficult to work around. The issue is with events of type KeyEvent.KEY_TYPED. Background: Typically this event is used to enter text into an editable text component. Sometimes unicode characters desired as "typed" characters can be composed of multiple key presses, for example a German PC-Type keyboard has no keys for characters like [ ] { } \ @ To type a '@' on a PC with such a keyboard running Windows, you type Alt-Gr + 'Q' , this produces the character '@'. More Alt-Gr sequences exist for the other characters mentioned above, among others: Alt-Gr + '7' ==> '{' Alt-Gr + '8' ==> '[' Alt-Gr + '9' ==> ']' Alt-Gr + '0' ==> '}' Alt-Gr + '2' ==> '��' Alt-Gr + '3' ==> '��' Alt-Gr + '+' ==> '~' Alt-Gr + '��' ==> '\' ... etc ... Btw. the newest addition is Alt-Gr + 'e' ==> the new euro currency sign The Problem: The events generated for KeyEvent.KEY_TYPED differ between windows and solaris, neither of which seem correct. On windows, pressing some combinations of keys generates a typed event that has modifiers. If one presses ALT + 'n' for example, a key typed event will be generated with a character of n and a modifier of ALT. This event isn't really wanted at all since it's not a printable character and doesn't represent a unicode character. If an Alt-Gr + 'q' is typed, the desired key typed event is generated, with modifiers although it's not clear one wants the modifiers in this case. On solaris, pressing some combinations of keys generated a typed event as well, but never with modifiers. This is even worse than on the PC. Pressing ALT + 'n' will produce a typed event with a character code of 'n' and no modifiers. This appears as if the user typed an 'n'. When typing accellerators, this will cause text to be added to the text component that is not desired, and there is no way to filter it out. I'm transferring this bug to classes_awt as it's a problem with the native awt. timothy.prinzing@eng 1998-08-27 There are a number of bugs having to do with KEY_TYPED event problems. (See also 4024849, 4028470, 4069196, 4153069, 4114565, and 4100317.) They need to be fixed, but it would probably be too risky to wade into this so close to code freeze. Since this bug doesn't cause a hang or crash (or comparably severe problem), it probably doesn't meet the criteria for fixing at this late date, so I'm moving it to a P4. We'll move this to the top of the list right after fcs. eric.hawkes@eng 1998-09-01 Name: vuC71690 Date: 04/05/99 This bug have different causes on Win32 and Solaris. On Win32 the problems is that Swing receives InputMethodEvent's instead of KEY_TYPED KeyEvent's. This is reported under 4186905: "JTextPane no longer dispatches keyTyped events to a KeyListener" filed against classes_awt_im. On Solaris the problem is missing ALT modifier on the KeyEvent. See 4220772: "Key modifiers not passed for KEY_TYPED events on Solaris" ###@###.### 1999-04-05 ====================================================================== Fixed the Solaris version of this: 4193779 A test case for this bug (both Solaris and Windows) is at: jdk:/ws/jdk1.3/test/java/awt/swing/event/KeyEvent/MenuShortCut eric.hawkes@eng 1999-04-08 The windows version of this has also been fixed. eric.hawkes@eng 1999-08-06
08-04-1999
WORK AROUND Remove the focus from the TextArea before using a menu accelerator, or delete the unwanted character after using one. eric.hawkes@eng 1998-09-01
01-09-1998

Duplicate :	JDK-4200559 - setMnemonic not consuming key...
Duplicate :	JDK-4176985 - Alt-2 accelerator results in chararacter added to text area
Duplicate :	JDK-4165650 - Swing-1.1beta2 - JComboBox with Java L&F has problems with posting menus.
Duplicate :	JDK-4160723 - Menu's accelerator key propagates to textfields
Relates :	JDK-4301105 - When tried ShortCut key alt+n, n was input in Text Area.
Relates :	JDK-4193779 - Modifiers not delivered with KEY_TYPED events on Solaris.
Relates :	JDK-4186905 - JTextPane no longer dispatches keyTyped events to a KeyListener
Relates :	JDK-6422318 - Japanese Input Dialog activated when using keyboard shortcuts