<AWT Dev> [9] Review request for 8028617: Dvorak keyboard mapping not honored when ctrl key pressed

anton nashatyrev anton.nashatyrev at oracle.com
Fri May 23 15:35:18 UTC 2014

Hello Petr,

     yes, I've run java/awt/event/KeyEvent tests from both open/closed 
parts: there were a number of fails on a clean build, but no new fails 
found with a fixed version (even one of them became 'passed').
     I couldn't invent any automatic regression tests since the problem 
is reproducible only with non-querty layouts.

     No, we are using the workaround now: the character is calculated 
from the keyboard scan-code (which is also received in the NSEvent) when 
the NSEvent::characters is empty. Thus we are still getting the right 
character in the querty layout, but having a problem with others (e.g. 
when the Ctrl-e is pressed on the dvorak layout (E corresponds to qwerty 
'D') we are getting Ctrl+d.)


On 23.05.2014 19:23, Petr Pchelko wrote:
> Hello, Anton.
> Did you run all the KeyEvent-related regression tests?
> May be we could right a regression test for this one? From your evaluation I have an impression that Ctrl+Key combination is now broken in normal layout too? Is this correct?
> Thank you.
> With best regards. Petr.
> On May 23, 2014, at 7:14 PM, anton nashatyrev <anton.nashatyrev at oracle.com> wrote:
>> Hello,
>>     could you please review the following fix:
>> fix: http://cr.openjdk.java.net/~anashaty/8028617/9/webrev.00/ <http://cr.openjdk.java.net/%7Eanashaty/8028617/9/webrev.00/>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8028617
>>     Problem: Dvorak keyboard mapping not honored when Ctrl key pressed
>>     Evaluation:
>>         The problem is in the AWTView.m:deliverJavaKeyEventHelper(): for taking a character we use NSEvent::characters which works fine until the Ctrl modifier is pressed. In this case the 'charaters' returns empty string. The typed character is then calculated via key code using the standard keyboard layout. Of course that doesn't work for any other layout including DVORAK.
>>     Fix: We should use NSEvent::charactersIgnoringModifiers property instead (especially taking into account that sun.lwawt.macosx.event.NSEvent constructor parameter name is 'charactersIgnoringModifiers')
>> Thanks!
>> Anton.

More information about the awt-dev mailing list