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

Andy Goryachev angorya at openjdk.org
Fri Aug 16 17:06:24 UTC 2024


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.

is there a compelling reason we are not using Event::isConsumed?

Maybe this case should also propagate `::isConsumed` flag similarly to #1523 

It looks to me we are trying to invent band-aids to what appears to be a design problem (cloning the events regardless of their `::isConsumed` state)

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

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


More information about the openjfx-dev mailing list