As part of the fix to 4515762 we noticed that there are a lot of keyEvent dispatches originating from the MenuSelectionManager.processKeyEvent. Essentially, the KeyEvent is forwared to every element that could be in the selection path. Before the event is dispatched, the path for that menu element must be constructed. The order for which this event is dispatched starts from the leaves (JMenuItems) and works its way up to the JPopupMenu and JMenu if the event is not consumed.
Part of the solution in 4515762 was to handle KeyEvents intended for the JMenuItems to be handled by the parent JMenu. The JMenu can scan all the JMenuItem elements and dispatch the action to a JMenuItem that has the matching mnemonic. This is fine for JMenuItems which are within the containment of a JMenu but doesn't work for stand alone JPopupMenus. The MenuKeyHandler in BasicMenuItemUI was maintained because of this reason.
The real solution is to consolidate the actions of the MenuKeyHandlers in both the BasicMenuItemUI and BasidMenuUI into a MenuKeyHandler in JPopupMenu. This would require adding semantics to JPopupMenu.processKeyEvent(KeyEvent, MenuElement[], MenuSelectionManager) so that it would translate the KeyEvent into a MenuKeyEvent and dispatch it to a MenuKeyHandler within BasicPopupMenuUI.
Another pursuit thats worth examining is to look at the shortcutting the keyEvents that originate from BasicPopupMenuUI. All those KeyEvents are dispatched to the MenuSelectionManager. Perhaps we can look at having the BasicPopupMenuUI handling and interpretting KeyEvents to that they can be dispatched to the intended menu item.
Another examination could be changing the semantics of processKeyEvent in MenuSelectionManager. Perhaps the keyEvent can be dispatched to the JMenu or JPopupMenu before the dispatching it to the individual JMenuItems. That would give the parent components a chance to dispatch the event to the correct JMenuItem and consume the event.