<Swing Dev> [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

[Anton Litvinov]

Hello Sergey,

Thank you very much for review of this fix. The second version of the 
fix with minor changes in 3 places which address your remarks is 
created. The new fix version applied to the today's version of the 
consolidated repository "jdk10/client" was verified in my local 
environment successfully. Could you please look at the new version of 
the fix.

Webrev (the 2nd version): 
http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01

The 2nd version of the fix contains the next changes:
1.  "SunToolkit.java" file - Now "true" is used as the default value for 
the system property "awt.touchKeyboardAutoShowIsEnable".
2.  The 1st version of the fix was not thread-safe, only in case, when 
more than 1 EDT could exist in the process, in 2 places: "WToolkit.java" 
file (access to the fields "compOnTouchDownEvent", 
"compOnMousePressedEvent"), "awt_Toolkit.cpp" file (deletion and 
assignment of "NULL" to the field "m_touchKbrdExeFilePath" in the method 
"ShowTouchKeyboard()").
     - "WToolkit.java" - The modifier "volatile" was added to the fields 
"compOnTouchDownEvent", "compOnMousePressedEvent".
     - "awt_Toolkit.cpp" - Code deleting and assigning NULL to 
"m_touchKbrdExeFilePath" in the method "ShowTouchKeyboard()" was 
substituted for the code which outputs into the trace message in case, 
if launching the touch keyboard system application fails.

Could you please answer my question.
- Should CCC request be filed for the new system property 
"awt.touchKeyboardAutoShowIsEnable", whose value is considered as "true" 
by default, if it is not specified by the user explicitly while 
launching a Java application?

Thank you,
Anton

On 05/09/2017 18:15, Sergey Bylokhov wrote:
> Hi, Anton.
> The fix looks good.
>  - But can you please recheck that is is not necessary to use 
> additional synchronization in showOrHideTouchKeyboard() if a few EDT 
> will be used.
>  - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use 
> true as default value, we will have more coverage and feedback in this 
> case. This property will be used as a workaround if some bugs will be 
> found.
>
> On 8/30/17 11:51, Anton Litvinov wrote:
>> Hello dear reviewers,
>>
>> Could anybody please look at this review request?
>>
>> Thank you,
>> Anton
>>
>> On 17/08/2017 13:20, Anton Litvinov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix for the bug.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00
>>>
>>> The bug is the fact that, when a user touches any Swing or AWT text 
>>> component, for example "JTextField", "JTextArea", "TextField", 
>>> "TextArea", by means of a touch screen on a host with MS Windows 
>>> 10/8.1/8 OS, the system touch keyboard is not shown automatically. 
>>> Please find a detailed description of the bug, screenshots depicting 
>>> the touch keyboard and a compilable test case with Swing/AWT text 
>>> components in JBS bug record. Also a summary of the done research of 
>>> the issue with a description of identified approaches for its 
>>> resolution are reported in my last comment in the bug record.
>>>
>>> THE FIX:
>>> On a very abstract level the fix functioning can be presented by the 
>>> next 3 stages:
>>>
>>> Stage 1.
>>> The fix adds support of "WM_TOUCH" system window messages to AWT 
>>> native peer windows through C++ class "AwtComponent". It "processes" 
>>> "WM_TOUCH" message and marks "java.awt.event.MouseEvent", which is 
>>> created as a result of handling of the further coming 
>>> "WM_LBUTTONDOWN", "WM_LBUTTONUP" messages sent by the system in 
>>> substitution for this "WM_TOUCH" message, by the new private field 
>>> flag "MouseEvent.causedByTouchEvent".
>>>
>>> Stage 2.
>>> Then on Java level the fix handles "MouseEvent", "FocusEvent" 
>>> received only by the instances of "java.awt.TextComponent", 
>>> "javax.swing.text.TextComponent" in 
>>> "WToolkit.showOrHideTouchKeyboard()" called from 
>>> "Component.dispatchEventImpl()" and shows or hides the touch 
>>> keyboard on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" 
>>> events by calling corresponding native methods of "WToolkit" class.
>>>
>>> Stage 3.
>>> Showing of the touch keyboard is implemented in C++ class 
>>> "AwtToolkit" and is done by launching the system application 
>>> "TabTip.exe" which implements the system touch keyboard. This 
>>> approach is described in the bug record.
>>>
>>> FEATURES OF THE FIX:
>>> 1. By default all native and Java parts of the fix do not function 
>>> at all - the fix is disabled. To enable the fix the application 
>>> should be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" 
>>> option. Handling of this new property is implemented in 
>>> "sun.awt.SunToolkit" class.
>>>
>>> 2. Native parts of the fix functions only on MS Window 8 or later.
>>>
>>> 3. The fix implements automatic showing of the touch keyboard for 
>>> the following 2 use cases:
>>>     a.  The user touches the text components using the touch screen.
>>>     b.  The user does mouse clicks on the text components, while no 
>>> any keyboard is attached to the host.
>>>
>>> FIX LOGICAL STRUCTURE BY SOURCE CODE:
>>> 1. Core of the fix:
>>>     Native code:  awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 
>>> awt_MouseEvent.[h/cpp], awt.h
>>>     Java:  SunToolkit.java, WToolkit.java, Component.java, 
>>> MouseEvent.java, AWTAccessor.java
>>>
>>> 2. Changes in all remaining Java files are connected with retaining 
>>> of the flag value "MouseEvent.causedByTouchEvent" during creation of 
>>> the new instances of "MouseEvent" class based on the original 
>>> "MouseEvent" instances.
>>>
>>> Work of the fix was verified both in the environment with the real 
>>> touch screen device and in the environment with the emulated touch 
>>> screen.
>>>
>>> Thank you,
>>> Anton
>>
>
>