popUpStatusItemMenu bug on macOS Catalina

Hi!


Well, It seems there is a bug on macOS Catalina when using several monitors in vertical disposition, main one below. If you click on the status bar over a NSStatusItem under this configuration, and the app uses popUpStatusItemMenu to pop the menu, then it doesn't work when clicked on the main monitor. No error log either.., just nothing appears.


I know it's a strange behaviour, but could reproduce it with several apps, including testing ones. I also know this method has been deprecated on 10.14, but that doesn't mean it shouldn't work and in fact, with Mojave, the method works perfectly fine under same circumstances.


When using other alignments (left to right and so on) this doesn't happen.


Opened a case: FB7456388


Thanks for reading! Hope this gets fixed on current Catalina beta.

Replies

It has been deprecated on 10.14, yet you expect it to be "undeprecated" in 10.15? Interesting to say the least. Even if it is a bug, there is no way that it will be fixed since it is deprecated. I highly suggest you find a different solution and use something that isn't deprecated.

This seems to be a larger issue than just popUpStatusItemMenu being deprecated. The issue persists even when not using popUpStatusItemMenu. For example, see the code below which fails to display the NSStatusItem's menu when, and only when, displays are arranged/stacked vertically. When the displays are arranged horizonally, there is no issue.


self.statusItem = [[NSStatusBar systemStatusBar] statusItemWithLength: NSVariableStatusItemLength];

[self.statusItem.button sendActionOn: (NSLeftMouseUpMask|NSRightMouseUpMask)];

[self.statusItem.button setAction: @selector(statusItemClicked:)];


-(IBAction) statusItemClicked: (id) sender

{

NSEvent *currentEvent = [NSApp currentEvent];


// Right click conditions

if ((([currentEvent modifierFlags] & NSControlKeyMask) == NSControlKeyMask) ||

(([currentEvent modifierFlags] & NSCommandKeyMask) == NSCommandKeyMask) ||

(([currentEvent modifierFlags] & NSRightMouseUpMask) == NSRightMouseUpMask) ||

(([currentEvent modifierFlags] & NSRightMouseDownMask) == NSRightMouseDownMask) ||

([currentEvent type] == NSRightMouseDown) ||

([currentEvent type] == NSRightMouseUp))

{

[self showStatusMenu: self];

}

else

{

// do something besides showing the menu

}

}


-(IBAction) showStatusMenu: (id) sender

{

self.statusItem.menu = self.statusMenu;

[self.statusItem.button performClick:nil];

}


-(void) menuDidClose : (NSMenu *) someMenu

{

if (someMenu == self.statusMenu)

{

// re-configure statusitem

self.statusItem.menu = nil;

[self.statusItem.button sendActionOn: (NSLeftMouseUpMask|NSRightMouseUpMask)];

[self.statusItem.button setAction: @selector(statusItemClicked:)];

}

}

Exact.


And doc is pretty explicit:

Deprecated

Custom views should not be set on a status item. Use the

button
property instead.


class NSStatusItem : NSObject

var button: NSStatusBarButton? { get }

Sorry, but I’m afraid you’re getting confused here, no offence. It’s just two different concepts. No asking obviously for “undeprecation,” just for support, as most of languages/APIs, if not all, does.


In fact, there are A LOT of deprecated method/apis that keep working just fine, since it must! due to obvious compatibility reason, some even since 10.6. APIs are “forever”, or at least the serious ones (and Apple is) and unless you release a breaking change and/or end of support is announced, they must just work and be supported even when deprecated…. and this is not a breaking change since the method still exists/nor end of support has been announced. In fact, as I said above, the method was deprecated on Mojave and works perfectly fine with that version, and “almost” fine too in Catalina so.., yes, this is a bug to be fixed.

Hi,


Thanks, but sorry.., the method is “.menu”.., documentation is wrong (another thing to fix), but .h files are ok. Copying below:


- (void)popUpStatusItemMenu:(NSMenu *)menu NS_DEPRECATED_MAC(10_0, 10_14, "Use the menu property instead");


https://developer.apple.com/documentation/appkit/nsstatusitem/1535918-menu?language=objc


…and I can confirm that using it the issue is not present, but that’s not the point here. In order to maintain compatibility (this has been just deprecated, we’re not talking here about a method that has been deprecated for years/removed support) so I think it should be fixed.

I'm not the one getting confused. Apple clearly states that anything that is deprecated is no longer supported and should not be used.


You can't make a valid argument by saying that there are a lot of deprecated APIs, some since 10.6, that still work. It is pure luck that they still work, not because they are still supported. You are, in effect, asking for "undeprecation" when you ask for it to be supported.


I suspect that a lot of those deprecated APIs that "still worked" in the past are going to start creating problems. Catalina is completely 64 bit and the older 32 bit code simply will not work as expected. It's not like this just happened--we have been told about the transition for years.


Accept the fact: it is not a bug--it is something that is deprecated and should no longer be used.

Sorry, but wrong again! and 32 bits vs 64 it's a totally different thing!.., but in any case, as you said, they announced they'd unsupport that in the future.., and that hasn't happened yet with the method I'm talking about here.., so, it must/should be supported, since it's still included in the SDK and end of support for it hasn't been announced yet. Imagine a world where all deprecations meant incompatibilities.., you wouldn't be able to use many software if not constantly updated! that's why it's called "backward compatibility"..., and that's what I meant with "APIs are forever".


Of course, they can do what the want with macOS, but they're serious about these kind of things and most (if not all) APIs/languages follow the same principle: 1st, deprecate it -> 2nd unsupport it -> 3rd remove it, and Apple hasn't been an exception for years. If you read their release notes, you know what I'm talking about..., an example here

Carbon component-based Audio Units are deprecated and support will be removed in a future release.

https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes?language=objc


That method is still on phase one, since It hasn't been unsupported yet.. (or at least it's not docummented), and they always announce that..., so this is a bug, period. If they want to fix it or not is only up to them.

So, if you're so sure it's a bug, file a bug report. There is nothing users of this forum can do about it. Just Apple…

Hi! already did (first post), but wanted to share with all out there to be aware in case other apps are affected and a possible workaround/fix..., using the now recommended .menu property if able to make a new release.., or other one workaround (if any) without the need to release a new version.

SOrry, I did not re read the whole thread.


Thanks for the feedback and thanks to tell if you get some answer from the bug report.


In the meantime, wish you good continuation.

Hello! I'm running into the same issue. Did you find a workaround in the meantime? Are there any news regarding your bug report? Looking forward to hearing from you. Thanks!