JDK-8187970 : Touch keyboard is not shown for text components on a screen touch
  • Type: CSR
  • Component: client-libs
  • Sub-Component: java.awt
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 10
  • Submitted: 2017-09-26
  • Updated: 2017-10-10
  • Resolved: 2017-10-09
Related Reports
CSR :  

Introduce a new system property "awt.touchKeyboardAutoShowIsEnabled" allowing to completely disable the fix for JDK-8166772 which implements a support of automatic showing of the system touch keyboard on MS Windows 10/8.1/8 OS in case, if JDK-8166772 causes any regression.


Automatic showing of the system touch keyboard on touching Swing or AWT text components on MS Windows 10/8.1/8 OS is addressed in the bug JDK-8166772. The fix for JDK-8166772 is created and approved by 2 technical reviewers at (awt-dev@openjdk.java.net) e-mail alias by current moment. But the fix is rather big and, if it causes any regression, the system property "awt.touchKeyboardAutoShowIsEnabled" could allow to disable the fix both internally in JDK and from the side of a user, until the regression is resolved, instead of complete backing out of the fix.


The new system property "awt.touchKeyboardAutoShowIsEnabled":

 - is already implemented as part of the fix for JDK-8166772;
 - it accepts "true", "false" values and by default its value is considered "true", if the property is not set explicitly by the user;
 - can be set to "false" by default by a new fix, if the fix for JDK-8166772 causes a regression, and that will let to disable the fix for JDK-8166772, until the regression is resolved.


There are no any changes in the public API specification.

Property is defined in "src/java.desktop/share/classes/sun/awt/SunToolkit.java" file by the changes specified below as part of the fix for JDK-8166772.

Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01
--- old/src/java.desktop/share/classes/sun/awt/SunToolkit.java  2017-09-21 16:24:37.000000000 +0100
+++ new/src/java.desktop/share/classes/sun/awt/SunToolkit.java  2017-09-21 16:24:37.000000000 +0100
@@ -84,6 +84,9 @@
         if (AccessController.doPrivileged(new GetBooleanAction("sun.awt.nativedebug"))) {
+        touchKeyboardAutoShowIsEnabled = Boolean.valueOf(
+            GetPropertyAction.privilegedGetProperty(
+                "awt.touchKeyboardAutoShowIsEnabled", "true"));

@@ -1614,6 +1617,13 @@
     public abstract void ungrab(Window w);

+    public void showOrHideTouchKeyboard(Component comp, AWTEvent e) {}
+    private static boolean touchKeyboardAutoShowIsEnabled;
+    public static boolean isTouchKeyboardAutoShowEnabled() {
+        return touchKeyboardAutoShowIsEnabled;
+    }

      * Locates the splash screen library in a platform dependent way and closes

Hello Phil and Joe. Thank you very much for assessment of this CSR. No, it is not black and white and I am not sure that it will not be necessary to communicate this to the customers. I have been working on the issue JDK-8166772 for a long time and did my best to move it to resolution, and just was afraid of never finishing work on it. I am for addressing the bug JDK-8166772 in a correct way and therefore I will document this system property in the release notes and not in the API specification. I will have to back port the fix for JDK-8166772 with this system property at least to JDK 8, and therefore I will file a similar CCC request.

Since the CSR has already been filed, I'm voting to approve it. If you decide to not document/support this system property or remove it from the proposed fix, please indicate that by withdraw the CSR request.

If you don't intend to document the property, nor do you intend to provide information on it or its usage to customers (meaning not even a single one), then you don't need a CSR. But is it that black and white ? How sure can you be ? Even if there is no immediate intention to communicate this to customers, if you think there is a reasonable chance this might change in the future then the CSR may be prudent. If that chance is slim-to-none .. then I doubt the CSR is warranted and it can be filed at that time anyway.

The scope was changed from "SE" to "JDK", because today I have been explained by the colleague that "SE" means that the change described in this CSR would be obligatory for all implementations of Java SE 10 API Specification, and this is absolutely not what I meant. This change is only for JDK.

The fix for the bug JDK-8166772: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01 The 1st technical approval of the fix: http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013109.html The 2nd technical approval of the fix: http://mail.openjdk.java.net/pipermail/awt-dev/2017-September/013119.html