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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Fri Mar 15 22:30:32 UTC 2019

On 15/03/2019 05:54, Sergey Malenkov wrote:
> We have a major issue about unexpected AltGr in the keyboard layout
> that should not have AltGr at all:
> http://youtrack.jetbrains.com/issue/IDEA-206348
> Why you decided to support AltGr for every keyboard layout? It really
> breaks backward compatibility!

Even in your bug report the people complain that altGr key does not work, and
the only problem here is that it does not assigned by default.
But on the other side it is possible to set separate shortcuts
to the "Alt + Alt Graph + Enter"and "Alt + Enter":

> I think the main client is Swing and pressed AltGr that looks like
> 'Alt+AltGr+' breaks all Alt-based shortcuts defined in
> javax.swing.plaf.basic.BasicLookAndFeel#initComponentDefaults and
> other places. Now, if you press "alt LEFT", the "moveColumnLeft"
> action is performed only for the left Alt. And this also breaks a
> backward compatibility.

The term "all" is not so critical, there are only few such shortcuts, and it is
a good thing that potentially we can set different shortcuts for each.
This is a bug that these places were not updated, it is easy to fix since this
is not exposed via public API.
But we will get the same result if we will use the AltGr mask only.

> It is not backward compatible to use AltGr instead of right Alt in
> both cases. Instead of 'Alt+key' you will get 'AltGr+key' or
> 'Alt+AltGr+key', which are not bound to any action.

It is compatible to the specification of InputEvent.getModifiersEx():
KeyEvent event = new KeyEvent(new Button(), 0, 0,
                               ALT_DOWN_MASK | ALT_GRAPH_DOWN_MASK, 0);
   int onmask =  ALT_DOWN_MASK;
   if ((event.getModifiersEx() & (onmask | offmask)) == onmask) {

The code above works before and after the change for altGr.
But it will stop working if we will use altGr only, and it will be hard to argue
why the ALT flag is not set while alt key is pressed(since on some keyboards this key is
marked as alt and on some other altGr).

And as specially noted in the method above the code should not assume which
flags(and how many) were set by the actions, if such assumptions exists in
Swing itself they should be fixed as well.

> On Fri, Mar 15, 2019 at 9:27 AM Krishna Addepalli
> <krishna.addepalli at oracle.com> wrote:
>> Hi Sergey Malenkov,
>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>> In my personal experience, I did not find any instance, wherein a shortcut had left and right alt in it.
>> Although it is not impossible, it seems weird to define such shortcuts.
>> It would be helpful if you could point to some resources, wherein defining such shortcuts is acceptable.
>> Thanks,
>> Krishna
>>> On 14-Mar-2019, at 4:03 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
>>> I strongly don't like two masks for one key. If you press VK_ALT,
>>> ALT_DOWN_MASK should be set. If you press VK_SHIFT then,
>>> SHIFT_DOWN_MASK should be added to indicate that both keys are
>>> pressed. And if you press VK_ALT_GRAPH, only ALT_GRAPH_DOWN_MASK
>>> should be added. Otherwise, you can't distinguish the following key
>>> strokes: 'AltGr+Right' and 'Alt+AltGr+Right'. But these keystrokes are
>>> different and should invoke different actions. For example,
>>> 'Alt+Right' moves cursor to the next word
>>> 'Alt+Shift+Right' moves cursor to the next word AND adds all skipped
>>> characters to selection
>>> 'Alt+AltGr+Right' does nothing, because we do not assign this shortcut yet
>>> On Thu, Mar 14, 2019 at 12:09 AM Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>> On 13/03/2019 03:59, Sergey Malenkov wrote:
>>>>> I missed the "for ALT keys" in the bug title and thought that
>>>>> "KeyEvent.getModifiers() returns inconsistent values" was about
>>>>> incompatible behaviour on different platforms. In fact, JDK-8218917
>>>>> should be renamed to something like “The right Alt key on Mac should
>>>>> behave as Alt and must not break the left Alt key processing”.
>>>> But the "right Alt" should behave like a "left alt" already, it should use both flags:
>>>> the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).
>>>> So if the client will follow the spec below it should work as before, isn't it?:
>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()
>>>>> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>>>>>> Hi Sergey,
>>>>>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>>>>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>>>>>> instead of simple Alt. See
>>>>>>> https://sites.google.com/site/malenkov/java/141229
>>>>>> Right, but introducing this flag for the "left alt" could cause even more
>>>>>> issues, so this flag is set only for the right.
>>>>>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>>>>>> I found more issues with inconsistent key processing on different
>>>>>>> platforms. See http://sites.google.com/site/malenkov/java/190312
>>>>>> Not sure that CAPS_LOCK is related.
>>>>>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>>>>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>>>>>> and I am sure has never been applicable to any MacOS.
>>>>>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>>>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>>>>>> https://help.ubuntu.com/community/ComposeKey
>>>>>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>>>>>> in the process ...>
>>>>>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>>>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>>>>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>>>>>> causing regressions ?
>>>>>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>>>>>> -phil.
>>>>>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>>>>>> Hi, Phil.
>>>>>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>>>>>> distinguish the left/right alts.
>>>>>>>> --
>>>>>>>> Best regards, Sergey.
>>>>>> --
>>>>>> Best regards, Sergey.
>>>> --
>>>> Best regards, Sergey.
>>> --
>>> Best regards,
>>> Sergey A. Malenkov

Best regards, Sergey.

More information about the awt-dev mailing list