JDK-8200353 : Shift or Capslock not working in Textfield after accented keystrokes
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8u152,9,10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2018-03-27
  • Updated: 2019-01-17
  • Resolved: 2018-06-13
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.
JDK 11 JDK 8
11 b19Fixed 8u192Fixed
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) Client VM (build 25.161-b12, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 32-bits
Windows 7 64-bits

EXTRA RELEVANT SYSTEM CONFIGURATION :
French keyboard

A DESCRIPTION OF THE PROBLEM :
Shift or Capslock stop working in java.awt.Textfield, leading to severe text input issue.
It always happens on Windows 7, either 32-bits ou 64-bits.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Send accentued keystrokes, whith keys combination like "�� �� ��" to java.awt.Textfield
Then, Shift or Capslock, Alt Gr don't work anymore in that Textfield.
Also Control shorcuts behave incorrectly.

Character "��" doesn't trigger the bug as it's typed on a single key, on the french keyboard.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Shifted keystrokes should be displayed in the Texfield.

ACTUAL -
It continue to works like if the Shift / Caps / Alt Gr key was not pressed, but it is.

Also shorcuts like [Control]+[key] behave differently.
For instance, Control+v pastes clipboard but also add an uneeded additionnal "v"



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

import java.awt.Frame;
import java.awt.TextField;
import java.awt.event.*;

public class TestKeysWin7 extends Frame implements WindowListener
{
	MyField field;
	
    public static void main(String args[])
	{
		TestKeysWin7 app = new TestKeysWin7();
	}
	
	public TestKeysWin7()
	{
		field = new MyField();
		
		setVisible(true);
		add(field);
		setSize(800, 100);
		
		addWindowListener(this);
	}

    public void windowOpened(WindowEvent e) {}

    public void windowClosing(WindowEvent e)
	{
		System.exit(0);
    }

    public void windowClosed(WindowEvent e) {}

    public void windowIconified(WindowEvent e) {}

    public void windowDeiconified(WindowEvent e) {}

    public void windowActivated(WindowEvent e) {}

    public void windowDeactivated(WindowEvent e) {}
    
    
    public class MyField extends TextField implements KeyListener
	{
		public MyField()
		{
			addKeyListener(this);
		}

		public void keyPressed(KeyEvent e)
		{
			int code = e.getKeyCode();
			System.out.println("Pressed key [" + KeyEvent.getKeyText(code) + "]");
		}
		
		public void keyReleased(KeyEvent e)
		{
			int code = e.getKeyCode();
			System.out.println("Released key [" + KeyEvent.getKeyText(code) + "]");
		}
		
		public void keyTyped(KeyEvent e)
		{
			char ch = e.getKeyChar();
			int mod = e.getModifiers();

			if (mod > 0)
			{
				System.out.print("Typed keys [" + KeyEvent.getKeyModifiersText(mod) + "]");
				System.out.print(" char [" + ch + "]");
				System.out.println("");
			}
			else
			{
				System.out.println("Typed char [" + ch + "]");
			}
		}
	}
}
---------- END SOURCE ----------


Comments
The new mechanism of dead keys detection and processing was introduced by JDK-8139189. According to that changes dead key input is activated by WM_KEYDOWN and deactivated by WM_CHAR messages. However the function WindowsKeyToJavaChar() (which actually sets the flag deadKeyActive to true) is also called from _NativeHandleEvent() and in this case target component doesn't receive WM_CHAR message, (i.e. dead key input remains active). At the same time _NativeHandleEvent() sends character back to the native window using WM_AWT_FORWARD_CHAR message. So it is necessary to disable dead key input, (i.e. set deadKeyActive to false) when WM_AWT_FORWARD_CHAR is received.
11-06-2018

I guess it is related to JDK-8139189/JDK-8169355 in some cases we did not deactivate the deadcode input. Dmitry, can you take a look the testcase is similar to the case you previously fixed.
29-05-2018

Reported with Windows 7 (32, 64-bit) JDK 8u161 French Keyboard Typing accentuated keystrokes with keys comibnation like �� �� �� �� in java.awt.Textfield followed by Capslock of Shift kets fails to work. Post this step, the character case in Windows continue to type in CAPS only when switched to English. To regain normal behavior had to restart the system. This behavior is obsreved randomly. Results: ======= 8: OK 8u151: OK 8u152: Fail 8u161: Fail 8u172 b03: Fail 10 b46: Fail 11 ea b05: Fail To reproduce (Checked with Windows 7 and Windows 10), Install French keyboard in Windows 7 Run the attached test case with respective JDK versions Switch to French input from language bar Type �� - Use following key combination to type this character -> "e)" (without quotes). Similarly type �� �� �� characters in the textfield. Subsequently, press CAPS LOCK and type any character. Observed that the CAPS LOCK key action failed to execute. In some cases, the occurrence appears upon multiple key press only. Note: Works fine when typing normal characters (non-accentuated). This is a possible regression in JDK 8u (need to identify the actual introduced in version).
29-03-2018