<AWT Dev> <AWT dev>[9] Review request for JDK-8155740: [macosx] robot.keyPress and robot.keyRelease do not generate key event for Alt-Graph key VK_ALT_GRAPH.

Semyon Sadetsky semyon.sadetsky at oracle.com
Tue Jun 14 09:47:05 UTC 2016 

Hi Manajit,

Could you improve the alignment of lines 272-286?

--Semyon


On 6/13/2016 2:29 PM, Manajit Halder wrote:
> Hi Semyon and Sergey,
>
> Code is modified as per the comment. Please review the modified webrev.
>
> http://cr.openjdk.java.net/~mhalder/8155740/webrev.04/ 
> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.04/>
>
> webrev.02 did not work because -
> The input nsFlag (modifier value) passed to the function 
> NsKeyModifiersToJavaModifiers was not correct. The calculation of 
> modifierwas not wrong and hence wrong modifier values was returned 
> from the method.
>
> Test cases run:
> Remaining two tests present in 
> https://java.net/jira/browse/MACOSX_PORT passed with the fix.
> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>
> Thanks,
> Manajit
>
>> On 01-Jun-2016, at 11:24 pm, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> Hi Manaji,
>>
>> Okay, back to werev.01.
>>
>> Could you remove the comment in lines 262-268 since you assume that 
>> it is not true anymore and so CGEventCreateKeyboardEvent/CGEventPost 
>> will not cause any troubles.
>>
>> Did you analyze why werev.02 fix did not pass those tests?
>>
>> --Semyon
>>
>>
>> On 6/1/2016 4:46 PM, Manajit Halder wrote:
>>> Hi  Semyon and Sergey,
>>>
>>> After running the tests shared by Sergey I found that the second 
>>> webrev (webrev.01) shared by me solves the problem.
>>>
>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Emhalder/8155740/webrev.01/>
>>>
>>> Following tests were present in 
>>> https://java.net/jira/browse/MACOSX_PORT-621:
>>> closed/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>> java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
>>> java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
>>>
>>> But only first test (which is now present as part of open code) 
>>> could be performed and the remaining tests were not found in the 
>>> present code.
>>> The first test fails due to another issue (JDK-8156460), whose fix 
>>> is in progress and will be send for after this issue. This fix 
>>> (JDK-8155740) is not related to the failure of the first test case.
>>>
>>> The new location of the first test:
>>> java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest
>>>
>>>  Please review the webrev.01.
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 26-May-2016, at 1:05 pm, Semyon Sadetsky 
>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>>>
>>>> On 5/24/2016 2:09 PM, Manajit Halder wrote:
>>>>
>>>>> Hi Semyon,
>>>>>
>>>>> It is not clear in the comment what was the problem, but it looks 
>>>>> like the problem was observed just by 
>>>>> using CGEventCreateKeyboardEvent/CGEventPost. In my case I don’t 
>>>>> see any issues just by using the fix. It posts all the key events 
>>>>> and all the key events are tested in the test file modified along 
>>>>> with the fix.
>>>> If you found the comment is not actual anymore, why did you 
>>>> preserve it?
>>>>
>>>> --Semyon
>>>>>
>>>>> Apart from the unknown problem mentioned in the existing comment 
>>>>> this fix has following advantages:
>>>>>
>>>>>   * Key codes for modifier key are required to distinguish between
>>>>>     Alt and Alt-Gr key, which is not possible by using existing
>>>>>     solution as it doesn’t post key codes for modifier keys. And
>>>>>     also keys can’t be distinguished base on modifier value, which
>>>>>     is same for both keys (Alt and Alt-Gr).
>>>>>   * As mentioned in the existing
>>>>>     comment CGEventCreateKeyboardEvent/CGEventPost is a better
>>>>>     solution.
>>>>>   * Online search about keyboard simulation showed
>>>>>     that CGEventCreateKeyboardEvent/CGEventPost is used to
>>>>>     simulate key stores in most of the cases.
>>>>>   * Tested the key codes, didn’t observe any problem.
>>>>>
>>>>>
>>>>> Regarding number keys not working 
>>>>> with CGEventCreateKeyboardEvent/CGEventPost:
>>>>> Solved the problem by providing event source 
>>>>> to CGEventCreateKeyboardEvent. Code is modified.
>>>>>
>>>>> Please review the modified code:
>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Manajit
>>>>>
>>>>>> On 20-May-2016, at 12:02 am, Semyon Sadetsky 
>>>>>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Manajit,
>>>>>>
>>>>>> Before your fix all key codes wa sent using
>>>>>>
>>>>>> AXUIElementCreateSystemWide();
>>>>>>
>>>>>> and CGEventCreateKeyboardEvent was commented or excluded from 
>>>>>> compilation:
>>>>>>
>>>>>> 274 #if 0
>>>>>>  275     CGEventRef event = CGEventCreateKeyboardEvent(NULL, 
>>>>>> keyCode, keyPressed);
>>>>>>  276     if (event != NULL) {
>>>>>>  277 CGEventPost(kCGSessionEventTap, event);
>>>>>>  278         CFRelease(event);
>>>>>>  279     }
>>>>>>  280 #endif
>>>>>>
>>>>>> I just wonder why it was done. Maybe that was some other issue 
>>>>>> fix. The comment above states:
>>>>>>
>>>>>>  262      * Well, using CGEventCreateKeyboardEvent/CGEventPost 
>>>>>> would have been
>>>>>>  263      * a better solution, however, it gives me all kinds of 
>>>>>> trouble and I have
>>>>>>  264      * no idea how to solve them without inserting delays 
>>>>>> between simulated
>>>>>>  265      * events. So, I've ended up disabling it and opted for 
>>>>>> another approach
>>>>>>  266      * that uses Accessibility API instead.
>>>>>>
>>>>>> I don't understand what trouble is mentioned in the comment 
>>>>>> above. But in your fix you've put the CGEventCreateKeyboardEvent 
>>>>>> back, may it return this trouble back?
>>>>>>
>>>>>> Also as I understand Numpad number keys did not work as well. 
>>>>>> Could you add the corresponding test case since you provide a fix 
>>>>>> this extra issue?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 5/13/2016 11:50 PM, Manajit Halder wrote:
>>>>>>> Hi Semyon,
>>>>>>>
>>>>>>> The fix is changed a bit because it was observed that the 
>>>>>>> modifier keys plus alphabet keys were not working together. In 
>>>>>>> the modified fix only Num keys are posted by 
>>>>>>> AXUIElementPostKeyboardEvent and remaining keys are posted by 
>>>>>>> CGPostKeyboardEvent/CGEventPost. The fix is explained in the 
>>>>>>> comment in file CRobot.m.
>>>>>>>
>>>>>>> Please review the new changes:
>>>>>>> _http://cr.openjdk.java.net/~mhalder/8155740/webrev.01/_
>>>>>>> _
>>>>>>> _
>>>>>>>
>>>>>>> Answers to your questions:
>>>>>>>
>>>>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>>>>> CGEventCreateKeyboardEvent?
>>>>>>>
>>>>>>> Difference as per the documentation:
>>>>>>> AXUIElementPostKeyboardEvent is similar to CGPostKeyboardEvent 
>>>>>>> (which synthesizes a low-level keyboard event on the local 
>>>>>>> machine), but it allows you to specify the target application as 
>>>>>>> opposed to always sending the events to the active application. 
>>>>>>> If the system-wide accessibility object is passed in the 
>>>>>>> application parameter, the event is sent to the active application.
>>>>>>>
>>>>>>> Difference behaviour as per the implementation observed while 
>>>>>>> debugging the code:
>>>>>>> AXUIElementPostKeyboardEvent:
>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all the 
>>>>>>> modifier keys with key codes 16, 17,18, 20, 157 and also for 
>>>>>>> newly added modifier key VK_ALT_GRAPH. But it posts correct key 
>>>>>>> code for all the remaining keys.
>>>>>>> While debugging it was that for modifier keys keyDown and keyUp 
>>>>>>> events are not generated, but flagsChanged event (flagsChanged: 
>>>>>>> (NSEvent *)event) is generated. But for all other keys keyDown 
>>>>>>> followed by keyUp events are generated.
>>>>>>>
>>>>>>> CGEventCreateKeyboardEvent:
>>>>>>> CGEventCreateKeyboardEvent posts correct key code for all the 
>>>>>>> keys except for numeric keys (numbers 0 to 9 on normal 
>>>>>>> keyboard). CGEventCreateKeyboardEvent posts wrong key codes for 
>>>>>>> the number keys 0 to 9. Instead of posting number key codes it 
>>>>>>> posts Numpad key codes for the corresponding number key. For 
>>>>>>> example Numpad0 key code is posted for number 0, Numpad1 key 
>>>>>>> code is posted for number 1 and simillarly for remaining num keys.
>>>>>>> Why the latter was commented? Does it mean that valid modifier 
>>>>>>> keys have not been sent by AWT robot?
>>>>>>>
>>>>>>> I didn’t get your question clearly. If you meant why in the 
>>>>>>> current implementation the later part (fix using 
>>>>>>> CGPostKeyboardEvent) of fix was commented.
>>>>>>> I am not very sure about it. As per the comment it is only clear 
>>>>>>> that CGPostKeyboardEvent/CGEventPost would have been a better 
>>>>>>> solution and I agree with that, perhaps reason could be related 
>>>>>>> to the difference in behaviour observed while debugging the code 
>>>>>>> as mentioned above.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Manajit
>>>>>>>
>>>>>>>> Hi Manajit,
>>>>>>>>
>>>>>>>> Just a few questions to clarify on the fix.
>>>>>>>> What is difference between AXUIElementPostKeyboardEvent and 
>>>>>>>> CGEventCreateKeyboardEvent?
>>>>>>>
>>>>>>>> Why the latter was commented? Does it mean that valid modifier 
>>>>>>>> keys have not been sent by AWT robot?
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/12/2016 10:45 AM, Manajit Halder wrote:
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> Kindly review the fix for JDK9.
>>>>>>>>>
>>>>>>>>> *Bug*:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155740
>>>>>>>>> _
>>>>>>>>> _
>>>>>>>>> *Webrev*:
>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8155740/webrev.00/
>>>>>>>>>
>>>>>>>>> *Issue: *
>>>>>>>>> [macosx] robot.keyPress and robot.keyRelease do not generate 
>>>>>>>>> key event for Alt-Graph key VK_ALT_GRAPH.
>>>>>>>>>
>>>>>>>>> *Cause: *
>>>>>>>>> VK_ALT_GRAPH is a new key added to the Mac OS X platform and 
>>>>>>>>> it is not mapped to any key on the OS X platform.
>>>>>>>>>
>>>>>>>>> *Fix: *
>>>>>>>>> VK_ALT_GRAPH is mapped to right option (OSX_RightOption) key 
>>>>>>>>> on Mac OS X.
>>>>>>>>>
>>>>>>>>> Method Java_sun_lwawt_macosx_CRobot_keyEvent is modified for 
>>>>>>>>> the following reason:
>>>>>>>>> AXUIElementPostKeyboardEvent posts 0 key code for all  the 
>>>>>>>>> modifier keys with key codes (16, 17,18, 20, 157) and also for 
>>>>>>>>> newly added modifier key VK_ALT_GRAPH.
>>>>>>>>> But it posts correct key code for all the other keys. On the 
>>>>>>>>> other hand CGEventCreateKeyboardEvent posts correct key code 
>>>>>>>>> for all the modifier keys and
>>>>>>>>> hence it is used to post modifier key events and 
>>>>>>>>> AXUIElementPostKeyboardEvent is used to post all the remaining 
>>>>>>>>> key events.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Manajit
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160614/16603257/attachment-0001.html>

More information about the awt-dev mailing list