On Mon, 14 Jul 2025 19:58:22 GMT, Martin Fox <m...@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
