MenuBar Mnemonics are ignored

[Deroin]

When focus is set onto the RichtText area and a MenuBar is added to the same Stage, pressing ALT will cause the MenuBar to highlight the first element, yet hitting any mnemonic key will not trigger the event to open the menu.

The mnemonic is working when focus is on any other element, so it's not a problem with JavaFX menu mnemonics. Also I tried overriding the event handler for onKeyTypedProperty to not consume any event which did not change anything on the bugged behavior. So besides the text area printing keys when ALT key is hold down and thus not letting mnemonics kick in, the event is somewhere caught in the middle and thus not propagated to menu properly.

[TomasMikula]

The mnemonic is working when focus is on any other element

Can you confirm it works on javafx.scene.control.TextArea?

Also I tried overriding the event handler for onKeyTypedProperty

Versions 0.7-* use addEventHandler to register event handlers. Therefore, setting onKeyTypedProperty doesn't override anything. You could use addEventFilter to prevent handling (and consuming) a specific event type.

So besides the text area printing keys when ALT key is hold down and thus not letting mnemonics kick in

I would say this is the correct behavior. Alt+? is a valid way of typing certain letters.

[Deroin]

Can you confirm it works on javafx.scene.control.TextArea?

Indeed i can, check out this code: https://gist.github.com/jakob-erdmann/be3eb9a658135f610ea971e983bde098

The upper area is a TextArea with Alt+F working to open the menu, the lower one is a CodeArea where ALT+F is printing an 'f' character.

Versions 0.7-* use addEventHandler to register event handlers. Therefore, setting onKeyTypedProperty doesn't override anything. You could use addEventFilter to prevent handling (and consuming) a specific event type.

I tested this with version 0.6.10 as we saw this as your latest stable release. But even in version 0.7-M2 I am able to reproduce the described behavior.

I would say this is the correct behavior. Alt+? is a valid way of typing certain letters.

I can agree on this as long as the combination should not be used for mnemonics or similar.

I also started some investigation on it, but for now the only thing I could notice is that on controls from javafx.scene.control package as event target, the eventDispatchChain is altered during event handling to include the MenuBar and thus all menues. For CodeArea as event target this did not happen.

Also to note: KeyCombinations on MenuItem.acceleratorProperty work as intended.

[TomasMikula]

I also started some investigation on it, but for now the only thing I could notice is that on controls from javafx.scene.control package as event target, the eventDispatchChain is altered during event handling to include the MenuBar and thus all menues.

Interesting. I would be interested to see the code that does this. I wasn't able to find it by a quick look at OpenJFX sources.

[Deroin]

I wasn't able to identify the exact place either, but will start another debug session during the weekend.

[Deroin]

I finally could pin down the issue a bit. During dispatching bubbling Events in com.sun.javafx.event.BasicEventDispatched:58 StyledTextAreaBehavior is consuming the key pressed event inside some lambda method. I could not identify the specific expression yet, but the consumption causes the event to not be propagated to KeyboardShortcutsHandler.dispatchBubblingEvent where mnemonics will be handled.

[alt-grr]

@TomasMikula

I would say this is the correct behavior. Alt+? is a valid way of typing certain letters.

Only Alt Gr a.k.a right Alt is for letters. Left Alt is for mnemonics.

[Deroin]

@TomasMikula

I would say this is the correct behavior. Alt+? is a valid way of typing certain letters.

Only Alt Gr a.k.a right Alt is for letters. Left Alt is for mnemonics.

That's what I was curious about, but I couldn't find any specifications. Just noticed it from experience. I will try to change behavior to differ between Alt Gr and plain Alt.

[alt-grr]

@jakob-erdmann https://en.wikipedia.org/wiki/AltGr_key

[TomasMikula]

Thanks for investigating. This is likely the line where it gets consumed. The point of that line is to consume any key presses that also produce a KEY_TYPED event (since we handle the corresponding KEY_TYPED event). I don't know how to decide conclusively when a KEY_PRESSED event will have an "accompanying" KEY_TYPED event, so this was my approximation. The predicate noControlKeys will need to be changed to take the Alt/AltGr distinction into account (which might be platform specific). Ideas how to better deal with the issue are welcome (although I'm somewhat skeptical).

[Deroin]

This is likely the line where it gets consumed. The predicate noControlKeys will need to be changed

Confirmed. I have a working solution for linux system. Here AltGr does neither set isAltDown() nor isControlDown() flags while the character is correctly modified by the editor. Still need to verify this behavior on a windows system.

[TomasMikula]

Also, we should add a test case that fails with the current implementation.

[ghost]

@jakob-erdmann, mind posting your solution? I'm encountering the same issue on Linux.

[Deroin]

@DaveJarvis My fix for this is in #365 but as you can see in the discussion of this I still have to do some testing on Windows. Didn't have time to do this so far.