Various menu bar NSStatusItem issues with macOS 27

It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps.

  1. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983

On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried:

  • An NSTrackingArea attached to a subview of NSStatusBarButton
  • An NSTrackingArea attached directly to the status-bar button
  • Replacing NSStatusItem.view with a custom view
  • Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover
  1. NSStatusItem button highlight cannot be set programmatically. - FB23330269

The following code no longer has any effect (does not provide the highlight capsule):

NSStatusItem.button?.highlight(true)

  1. NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447

The following no longer works:

statusItem.button?.window?.occlusionState.contains(.visible)

These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.

All these seem to be broken in macOS 27 dev beta 3 (26A5378j) as well.

Update: to solve the button highlight issue, one should use NSStatusItem's new expandedInterfaceDelegate.

https://developer.apple.com/documentation/appkit/nsstatusitem/expandedinterfacedelegate

Mouse tracking and occlusion detection of an NSStatusItem (or its button) is still an unresolved issue, there is no modern alternative afaik.

But of course the expandedInterfaceDelegate does not solve the issue of programmatically creating a highlight (for the purposes of programmatically showing the menubar app window or showing an OSD interface tied to the menubar extra icon), so this is not a complete replacement - it just helps to fix the lack of highlight when an user starts interacting with the NSStatusItem.

Hello @Steve4442,

Thanks for filing these reports and providing a solution. I've included the highlight solution you shared in the report so the relevant engineering team is aware of this workaround.

As for the other two reports:

  • NSStatusItem buttons does not receive mouse hover/movement events - (FB23329983).
  • NSStatusItem window occlusionState no longer reflects hidden menu bar visibility (FB23349447).

Are you able to upload a minimal sample project that reproduces the issue? You can do this with Feedback Assistant

This way the engineering teams who receive your report can see exactly what you are seeing. If you share your code here as well, I and others can offer direct workarounds and suggestions if any are available.

Thank you for reporting! Updates generally are provided through Feedback Assistant, keep an eye on your reports for status updates.

 Travis

UPDATE:

The "NSStatusItem does not receive mouse hover/movement events on macOS" (FB23329983) seems to be fixed in macOS 27 dev beta 5 (build 26A5406e).

The following issues still remain:

  • inability to set NSStatusItem button highlight cannot be set programmatically (B23330269), for which expandedInterfaceDelegate gives a partial solution.
  • NSStatusItem window occlusionState no longer reflects hidden menu bar visibility (FB23349447)

Additionally, there is a somewhat serious design issue/oversight with expandedInterfaceDelegate and expandedInterfaceSession when it comes to implementing touch support. With a custom menu bar extra window implementation (when one uses a custom NSWindow or NSPanel and for the menu bar extra app's window together with the new expandedInterface..., instead of relying on the traditional NSMenu or NSPopover attached to a menubar extra status item) there is no mechanism at all to detect touch tap gesture outside of the window. This would be essential to figure out when the user wants to dismiss the menubar extra window.

Previously, the normal pattern was to use a global event monitor to act when the user clicks outside of the window - with this the app could trigger closing the menubar extra window. Touch events are not covered by this mechanism and there is no alternate API of any kind. So menubar extra apps (which do not use NSMenu or NSPopover or the basic SwiftUI menubar extra solution) simply don't have any means to detect the user intent to close the menubar extra window (when the user taps outside of the window). A less than ideal workaround may be to track loss of key window status maybe, but that is not fool-proof, especially if one designs an app in a way that the menubar extra window does not grab key status or focus at all.

Various menu bar NSStatusItem issues with macOS 27
 
 
Q