<AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

Krishna Addepalli krishna.addepalli at oracle.com
Mon Mar 11 10:53:10 UTC 2019

Hi Sergey,

Thanks for proposing a patch.
The feature of ALT_GR support on Mac was not done by me, however looking at the bug, and the fact that Mac doesn’t have “AltGR” key, I’m wondering if it makes sense to have code that emits ALT_GR code?

Also, even if we wanted to support it, I wouldn’t want to do it as a compile time flag. Ideally, it should be a flag that can be turned on/off at run time via a system property.

@Manajit, could you throw some light on why it was decided to implement this behaviour on Mac vis a vis disabling all those tests that rely on this behaviour for Mac?


> On 06-Mar-2019, at 11:02 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> Hi Krishna,
> Your fix solves the issue that the right Alt key breaks further
> processing of the left Alt key.
> But there is a problem with modifiers mask:
> 304         java_awt_event_InputEvent_ALT_DOWN_MASK |
> java_awt_event_InputEvent_ALT_GRAPH_DOWN_MASK,
> 305         java_awt_event_InputEvent_ALT_MASK |
> java_awt_event_InputEvent_ALT_GRAPH_MASK,
> 306         java_awt_event_KeyEvent_VK_ALT |
> java_awt_event_KeyEvent_VK_ALT_GRAPH
> Why did you merge VK_ALT and VK_ALT_GRAPH? This is key codes, not a mask.
> Why did you set ALT_DOWN_MASK and ALT_GRAPH_DOWN_MASK both if only the
> VK_ALT_GRAPH is pressed?
> Could you please provide a more complex test? For example,
>  robot.keyPress(KeyEvent.VK_ALT); // check that key code is VK_ALT
> and modifiers = ALT_DOWN_MASK
>  robot.keyPress(KeyEvent.VK_ALT_GRAPH); // check that key code is
>  robot.keyRelease(KeyEvent.VK_ALT); // check that key code is VK_ALT
> and modifiers = ALT_GRAPH_DOWN_MASK
>  robot.keyRelease(KeyEvent.VK_ALT_GRAPH); // check that key code is
> VK_ALT_GRAPH and modifiers = 0
> Note, if you replace ALT_GRAPH with SHIFT in the code above, all
> required events will be sent correctly.
> In the following article I provide a manual test and a simple patch to
> solve issues with pressing the left Shift key together with the right
> one.
> https://urldefense.proofpoint.com/v2/url?u=http-3A__sites.google.com_site_malenkov_java_190306&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=QF7AertWDY_M4hfHg_4S-iyX-aP0wtLYwZFgs0zfX_k&m=vpGiD5G2K4wQZbNL-H0ffHAEDEWj-433rJ1a-9zAeyE&s=P2SNOGSmKVcDyQuWHUuP9hs5wxjrqkdwtrOMGqv-tZg&e=
> Unfortunately I cannot create an automated test, because the Robot
> have no ability to press a key in the required location (left or
> right).
> On Wed, Mar 6, 2019 at 9:45 AM Krishna Addepalli
> <krishna.addepalli at oracle.com> wrote:
>> Hi All,
>> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8218917
>> With webrev: http://cr.openjdk.java.net/~kaddepalli/8218917/webrev00/
>> The problem is that once right alt key is pressed, pressing the left alt key always returns the key code for right alt key. The problem was in AWTEvent.m, there is a static variable “altGRPressed” which is being set once right alt is pressed, but is not being cleared when left alt key is pressed. The fix is to completely remove the “altGRPressed” variable as “leftAtlPressed” is sufficient to determine which alt key was pressed.
>> I have tested all the regressions associated with JDK-8156460, and found no new failures.
>> Thanks,
>> Krishna
> -- 
> Best regards,
> Sergey A. Malenkov

More information about the awt-dev mailing list