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. > To fix this we would have to introduce new API's (like some form of PR > https://github.com/openjdk/jfx/pull/1632). I am not a fan of #1632, I think it's an attempt to band-aid over a fundamental design issue, but this is a different topic altogether. Why would a Spinner or ComboBox consume the key events that it is not supposed to? Ok, let's assume the outer control (Spinner or ComboBox) gets the event and fires a copy to the inner control (TextField). This is perfectly legal, but now it must either consume the event if the secondary event is consumed. More importantly, it **should not consume** the event if the secondary event is not consumed, isn't that the issue? So it it a responsibility of the entity that creates the secondary event to either consume the original event or let it go, or am I mistaken? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1848#issuecomment-3075683925
