RFR: 8087863: Mac: "Select All" within ListView/TreeView is handled differently depending on the useSystemMenuBar value

[Martin Fox]

On Fri, 2 Aug 2024 19:07:35 GMT, Martin Fox <mfox at openjdk.org> wrote:

> macOS processes a shortcut key like Cmd+A in two phases. In the first phase it’s shopped around as a “key equivalent”. If it’s not consumed as a key equivalent it enters the second phase and processed as a normal keyDown event. Among other things the key equivalent phase ensures the shortcut will be seen by the system menu bar *before* being treated as a keyDown. This is the opposite of how JavaFX works; it expects a key event to be fired at the current focus node which gets first crack at the event before it works its way out to the menu bar.
> 
> We can’t really opt out of the key equivalent phase but we can get the event before the system menu bar does. Our implementation of performKeyEquivalent pushes the event through the JavaFX scene graph but has no way of knowing if the scene graph consumed it. The result is that a consumed event is always handed to the system menu bar where it can also trigger a menu item.
> 
> This PR introduces a variant of notifyKey that returns a boolean indicating whether the event was consumed or not. If the event was consumed performKeyEquivalent doesn’t allow it to continue on to the system menu bar.
> 
> I’m trying to fix this old, old problem because I’ve seen at least one JavaFX app tie itself up in knots trying to work around this. Despite the number of files being touched it is not a deep fix; there’s just a boolean return value that needs to be plumbed through multiple layers.

Taking this out of Draft. To ensure consistent handling of the IM both `keyDown:` and `performKeyEquivalent:` use the same routine. There's a check to ensure that the same event doesn't get processed twice which mimics an older check that used to be in the view delegate.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1528#issuecomment-2293854333