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 crash 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.

I'm marking this PR as draft for now. Turns out we're relying on double-processing of key events to make IM's work.

macOS sends a navigation key to us via performKeyEquivalent. That includes Home, End, and any arrow key. Currently we let the scene graph act on the event first and if a TextInput control has the focus the event is usually consumed. If we stop processing the event (and we should since it's consumed) it will never reach the IM.

In other words, the current system relies on having the same navigation key event sent to both performKeyEquivalent and keyDown. It gets acted on twice, once by the TextInput control and again by the IM. This is wrong but prioritizing the TextInput control over the IM is more wrong.

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

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