RFR: 8354539: [macOS] ComboBox and Spinner disable system menu bar shortcuts [v2]

Andy Goryachev angorya at openjdk.org
Tue Jul 15 18:01:56 UTC 2025


On Mon, 14 Jul 2025 19:58:22 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> The Mac platform code sends a KeyEvent into the scene graph and if the event is not consumed it gets sent on to the system menu. But ComboBox and Spinner always consume the original event and fire a copy which the system menu ignores.
>> 
>> In the past the platform code sent key events to the system menu even if the scene graph consumed them. This caused various bugs and was fixed in PR #1528 leading to this issue.
>> 
>> One could argue that a ComboBox or Spinner shouldn’t consume all key events but one could also argue that the system menu shouldn’t behave so differently from a standard MenuBar which will respond to any KeyEvent that reaches the top-level Scene no matter where it came from.
>> 
>> This PR installs an event dispatcher which forwards KEY_PRESSED events on to the platform so any event bubbling through the dispatch chain can trigger the system menu. The dispatcher is placed by the top-level (non-popup) Window such that it’s the last dispatcher encountered while bubbling.
>> 
>> In this PR once the key event reaches the GlassSystemMenu it passes the JavaFX key code and modifiers into the Mac platform code. This isn’t enough information to construct an NSEvent to pass to the main menu. Instead the code uses the code and modifiers to verify that the originating key down NSEvent (which it retained) should be sent on to NSApp.mainMenu.
>> 
>> (There are other ways this could work. GlassSystemMenu could take the KeyEvent and perform its own accelerator matching entirely inside Java. This would match the way the standard MenuBar finds accelerators instead of using Apple’s matching algorithm. This PR is the more conservative approach, basically just shifting the timing of system menu matching without changing how it’s done.)
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback related to code consistency and clarity.

On a surface, this looks like a rather intrusive change (I can't comment on the merits of this PR yet).

Would it make sense to attempt fixing event consumption bugs in the ComboBox and Spinner first?
And perhaps also look at fixing the dispatching of consumed events such as JDK-8303209 or JDK-8229467 (the latter has been by @mstr2 , I think prematurely)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3074723995


More information about the openjfx-dev mailing list