This repository was archived by the owner on Jun 24, 2021. It is now read-only.

Description
This is my interpretation of https://bugs.openjdk.java.net/browse/JDK-8088068
code to reproduce is in a comment below
The accelerator API appears to assume a kind of singleton menubar. The binding logic for accelerators uses the scene and is keyed only by the key combination. This is likely suitable for a large portion of users.
This has a surprising ramification for contextMenus using accelerators: if you create multiple instances of a MenuItem with an accelerator, one will overwrite the other, causing instance confusion.
I don't believe there is an obvious fix for this: the existing implementation is on the scene, and is keyed only by the key-combination (not the instance or any extra meta about who registered that key combination). As such there are certain to be implementations that rely on this behavior for functionality; for them the lack of instance-specificity is a convenience.
my .02:
I'm wondering if the accelerator system could be updated to include "local" vs "global" accelerators, with the existing API being an alias for global accelerators. I would then change MenuItem to include localAccelerator (is there a system for me to rename accelerator to globalAccelerator with backwards compatibility?) The binding logic could then traverse the node graph (specifically, the instigating event target's parent lineage) to find the most local accelerator, defaulting to the global accelerator.