<AWT Dev>  JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys
malenkov at gmail.com
Mon Mar 11 12:23:14 UTC 2019
> 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?
Sometimes it can be useful. For example, we can increase amount of
shortcuts in our IDE, i.e. Alt+F -> Alt+F & AltGr+F. But, we should
have an ability to turn this functionality off, because some Mac users
want to use Alt+arrows with the right Alt key.
> 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.
This is a good idea. I've added a flag without a system property only
to keep my patch as small as possible.
Sergey A. Malenkov
> > 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
> > VK_ALT_GRAPH and modifiers = ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK
> > 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