On Wed, 11 Mar 2026 00:46:22 GMT, Jose Pereda <[email protected]> wrote:
> This PR fixes https://bugs.openjdk.org/browse/JDK-8263959, an issue on macOS > that happens when a menu is disabled, and then enabled back again, where leaf > menuItems remain disabled unexpectedly, by re-syncing the native NSMenuItem > enabled state from Java menuItem enabled state. > > Explanation: We create the native NSMenuItems with `autoenablesItems:YES`, > which means the OS calls `GlassMenu::validateMenuItem:` on each item's target > to determine if it should be enabled. This calls the Java > `GlassSystemMenu::validate` callback, which updates the accelerator bindings, > but it doesn't update the enabled state: It remains as it was (in this case, > disabled when the parent menu was disabled) as `[glassTargetItem->item > isEnabled]` returns the old state (NO/disabled) rather than the updated Java > state (`!menuitem.isDisable()`/enabled). > > One possible and valid fix would be changing `autoenablesItems:YES` to > `autoenablesItems:NO`, as the Java layer already manages the enable state via > `GlassMenu::_setEnabled` (making `validateMenuItem:` redundant for this case). > > However, the proposed fix doesn't change that, and simply syncs the native > side with the Java side while validation is being performed. > > A system test has been included, if fails before this patch, passes after it. tests/system/src/test/java/test/robot/javafx/scene/SystemMenuBarEnableTest.java line 151: > 149: > 150: final AtomicBoolean enabledItemFired = new AtomicBoolean(false); > 151: final AtomicBoolean disabledItemFired = new AtomicBoolean(false); General pattern we have in other tests is that, such variables are declared as member of the public enclosing class. It would avoid the need of TestApp object reference for using these variables. I would recommend to move them, it would maintain similarity with existing tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2103#discussion_r2916942143
