[HeikoKlare]

Contributes to #3540

Problem

On macOS 27, items inserted into the main menu bar are not shown on screen until the mouse hovers over the menu bar or the application is activated again (e.g. by switching to another application and back). This affects:

• closing any child shell or dialog (the menu bar is swapped back to the parent shell's menu bar),
• adding a MenuItem to the active menu bar (e.g. while the workbench fills its menu bar at startup).

SWT updates the NSMenu correctly and in time; the update gets lost between AppKit and the system's menu bar. Removing or renaming top-level items is not affected.

Workaround

After inserting items into the main menu, re-assert it via NSApp.setMainMenu(nil) followed by NSApp.setMainMenu(menu), which forces AppKit to resync the menu bar. The menu is retained around the calls, as NSApp may hold the only reference to it.

• The refresh is executed asynchronously after the current event, both after Display.setMenuBar() and after Menu.createItem() adds an item to the active menu bar. Doing it synchronously within the key window change is sometimes ignored by AppKit (observed while a sheet closes). Being asynchronous, consecutive changes are coalesced into a single refresh.
• Only active on macOS 27 and later.

Lighter alternatives were tested and do not help: [NSMenu update], setting the same main menu again, and either of those executed asynchronously.

⚠️ This is a workaround, the root cause is unknown

We do not know why macOS 27 stops showing newly inserted menu bar items, and we could not find any documentation of a related AppKit change. This change does not fix a root cause in SWT; it forces AppKit to resync the menu bar. It may become unnecessary, or need adjusting, with future macOS updates, and it should be revisited once the cause is understood.

Still, it is the best solution we currently have, and we think it is better to ship this workaround for 2026-12 than to leave the menu bar broken for all SWT/Eclipse applications on macOS 27.

Testing (macOS 27, aarch64)

Verified with screenshots of the menu bar over time, with and without the change:

Scenario	Without change	With change
Child dialog (snippet 1 from the issue)	blank until hover or reactivation	visible after ≤ ~450 ms
Sheet dialog	blank until hover or reactivation	visible after ≤ ~450 ms
Item added to active menu bar (snippet 2 from the issue)	hidden until hover or reactivation	visible after ≤ ~300 ms
Many items added at once	–	visible after ≤ ~330 ms, single refresh
Item removed / renamed	immediate	immediate
Non-modal shell, MessageBox	immediate	immediate

Also checked manually: menus open normally after a refresh, and Cmd+H / Cmd+Q from the application menu still work. Test_org_eclipse_swt_widgets_Menu, MenuItem, Shell and Display pass with the same results as without the change.

🤖 Generated with Claude Code

[github-actions]

Test Results (macosx)

  336 files  ±0    336 suites  ±0   18m 54s ⏱️ - 10m 50s
4 788 tests ±0  4 416 ✅ ±0  372 💤 ±0  0 ❌ ±0 
9 852 runs  ±0  8 894 ✅ ±0  958 💤 ±0  0 ❌ ±0 

Results for commit e427468. ± Comparison against base commit 0182d2a.

♻️ This comment has been updated with latest results.

[Phillipus]

Thanks for this. I did a quick test with our RCP app and the snippets in #3540 and can confirm that this does work.

[Phillipus]

blank for ~3.3 s
blank for ~2.1 s
hidden for ~5.6 s

In practice for me they are blank/hidden forever or until mouse over.

[HeikoKlare]

In practice for me they are blank/hidden forever or until mouse over.

Sometimes (very seldom) they show up for me automatically after some time. But I can confirm that they usually stay blank until one of these two events happens:

• Mouse over the main menu
• The application windows loses and receives focus again

[gravemalte]

Thank you Heiko.

Should we maybe place a comment in form of a TODO: ... that we don't forget to recheck (and maybe remove the workaround in the future) when a new MacOS version releases? Otherwise I fear we will forget about it.

[HeikoKlare]

Thank you @Phillipus and @gravemalte for testing and for your feedback!

Your comments are addressed with the latest push:

• The description and the commit message no longer claim that the items appear after a few seconds. They now state that inserted items stay hidden until the mouse hovers over the menu bar or the application is activated again.
• A TODO in Display reminds us to re-evaluate the workaround with future macOS releases.

I have posted additional insights into the cause in the issue: #3540 (comment)
In short, this seems to be a macOS 27 regression that also occurs in a plain AppKit application without SWT (a minimal reproducer is included there), but SWT triggers it far more reliably. The root cause within macOS is still unknown, so this PR remains a workaround.

@soethoff @BeckerWdf @sratz since you probably have a particular interest in regressions of the SWT macOS port, I would appreciate the feedback from anyone of you on this change as well.

[Phillipus]

@HeikoKlare Thanks for your work on this.

For my own part I will test each macOS 27.x release to test if this might be fixed by Apple.

[Phillipus]

The menu problem is fixed in macOS 27.2 RC. See #3540 (comment)

[HeikoKlare]

Closing this as obsolete according to #3540 (comment)

The issue will be fixed with macOS 27.2.