RFR: 8339728 : [Accessibility, Windows, JAWS] Bug in the getKeyChar method of the AccessBridge class [v2]

[Alexander Zuev]

On Thu, 19 Dec 2024 05:28:16 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> For a JMenuItem with a shortcut like _Ctrl + Comma_, the `getKeyChar` method of the `AccessBridge` class cuts the _Comma_ text to the first character and hence transfers `C (instead of Comma)` via the `AccessBridge` API. For a shortcut _Ctrl + Comma_ in a menu item, screen readers announce _Ctrl + C_ instead of _Ctrl + Comma_ as shortcut. Same issue exists for **Enter, Period and other keys** as well where only the first character is returned from the getKeyChar method. 
>> 
>> Proposed fix is to ensure that the _char representation of the shortcuts_ is returned by the `getKeyChar` method and it worked fine except for **"Enter"** key. It is unclear to me why it has not announced by AT (JAWS) but I think that may be due to the char representation of the Enter key which is a Line Feed.
>> 
>> AT was also not able to announce the _Tab and Space_ key as a shortcut. Adding these keys in the control key list in _AccessBridge_ and in supported control code list in _AccessBridgePackages_ files enabled them to be announced by AT.
>> 
>> Manual test case is added to verify the shortcut for JMenuItems.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year and test update

src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 3975:

> 3973:         keyCode = keyStroke.getKeyCode();
> 3974:         debugString("[INFO]:   Shortcut is: " + Integer.toHexString(keyCode));
> 3975:         if (keyCode != 0) {

Why do we need this check? If keyCode is not zero we return keyCode but if it is zero we will still return keyCode because we return zero after the condition.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22822#discussion_r1896941143