1941595 - macOS main menu looks inactive after switching to Firefox

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P3)

Description

[Dave Townsend [:mossop]]

For the past few days I've found that frequently after launching or switching focus back to Firefox the main menu is invisible. The menu icons still appear on the right but where the menus should be there is just a blank space. Clicking in that space causes the menus to appear again.

Comment 1

[Stephen A Pohl]

Could you attach a screenshot of this? Is this referring to the main menu with the apple logo, followed by "Nightly", "Edit" etc.? Are the "menu icons" the icons for WiFi, Bluetooth etc., or something else?

Comment 2

[Dave Townsend [:mossop]]

Attachment: Working screenshot

(In reply to Stephen A Pohl [:spohl] from comment #1)

Could you attach a screenshot of this? Is this referring to the main menu with the apple logo, followed by "Nightly", "Edit" etc.? Are the "menu icons" the icons for WiFi, Bluetooth etc., or something else?

Sorry yes I wasn't terribly clear. But yes it is the apple logo and menus. The icons are the ones for wifi, bluetooth, date and time etc. Unfortunately starting the screenshot tool is one of the things that triggers the menus re-appearing. But imagine this screenshot but the apple logo and everything from "Firefox Nightly" to "Help" is missing and all the icons to the right are still present.

For some reason it seems to reproduce much more easily when I am connected to my external monitor, I'm having difficulty triggering it on my laptop display.

Comment 3

[Stephen A Pohl]

Might this reproduce with mozregression? We have landed a few changes recently to things that could affect the main menu, or menu items within the main menu, but nothing that should have triggered this kind of regression. In particular I'm thinking of bug 1935257 and possibly bug 1923666, which triggered a regression as noted in bug 1939346.

Comment 4

[Dave Townsend [:mossop]]

Attachment: Screen Recording

It is just reproducible enough that I managed to narrow it down to https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ee1296ebe22348312a0f575a4d82ad25c0394012&tochange=1543feed065207594a549e9a0d2738e0c39e9d2c.

Attached is a recording of how I was reproducing. Clicking on the desktop to hide the window, clicking again and then very quickly clicking on the window as it re-appears. As you can see it isn't completely reproducible but it was often enough that I'm reasonably confident this range is right, particularly given the patch it identified is related.

Comment 5

[Dave Townsend [:mossop]]

Attachment: Switching between spaces

Another way to reproduce is have two spaces open. Switching between the spaces with a keyboard shortcut or custom mouse button often triggers this. Interestingly when the space with Firefox in it is sliding back into view the menus are visible but then when Firefox gets full focus they disappear.

Comment 6

[Dave Townsend [:mossop]]

[Tracking Requested - why for this release]: A regression introduced by bug 1765391. Not sure how many people it is impacting though

Comment 7

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1765391

Comment 8

[Stephen A Pohl]

(In reply to Dave Townsend [:mossop] from comment #6)

[Tracking Requested - why for this release]: A regression introduced by bug 1765391. Not sure how many people it is impacting though

I believe fixing five crashes is more important than this rather hard-to-reproduce visual glitch that a user can recover from by clicking on the main menu. But I appreciate all the helpful steps and I'm going to try and address this regression. I have not been able to reproduce this issue yet but I'm going to keep trying.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

The latest patch for bug 1765391 did more than is strictly necessary to fix that bug's crashes. Here's a tryserver build that makes the minimal necessary changes. (I tested with the STR at bug 1765391 comment #61. The crashes only happen on macOS 13 and below. I tested on macOS 13.7.2.)

https://treeherder.mozilla.org/jobs?repo=try&revision=9fc377ac377eb49567fb82fdffcf408f8b7619d5
https://hg.mozilla.org/try/rev/1c3009ff53bffa531f021f0b739777c827fa659d
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Y_C9VyFuTwiEPuXkh3i1KQ/runs/0/artifacts/public/build/target.dmg

Please try this, mossop, to see if you can still reproduce this bug with it.

Note that, after you download target.dmg, you need to run xattr -c target.dmg on it before you open it. Otherwise the build you extract from it will fail to run.

Comment 10

[Dave Townsend [:mossop]]

I'll have to test this when I get home as it definitely seems to be triggered, or made much more likely by using an external monitor. Possibly why others aren't seeing it.

Comment 11

[Stephen A Pohl]

(In reply to Dave Townsend [:mossop] from comment #10)

I'll have to test this when I get home as it definitely seems to be triggered, or made much more likely by using an external monitor. Possibly why others aren't seeing it.

I have tested with external monitors as well, but still haven't been able to repro. What version of macOS are you using? And I'm assuming that you have "Displays have separate Spaces" selected in System Settings > Desktop & Dock, is this correct? Does it reproduce when this is switched off? You may have to log out and back in to change this setting.

Comment 12

[Dave Townsend [:mossop]]

(In reply to Steven Michaud [:smichaud] (Retired) from comment #9)

The latest patch for bug 1765391 did more than is strictly necessary to fix that bug's crashes. Here's a tryserver build that makes the minimal necessary changes. (I tested with the STR at bug 1765391 comment #61. The crashes only happen on macOS 13 and below. I tested on macOS 13.7.2.)

https://treeherder.mozilla.org/jobs?repo=try&revision=9fc377ac377eb49567fb82fdffcf408f8b7619d5
https://hg.mozilla.org/try/rev/1c3009ff53bffa531f021f0b739777c827fa659d
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Y_C9VyFuTwiEPuXkh3i1KQ/runs/0/artifacts/public/build/target.dmg

Please try this, mossop, to see if you can still reproduce this bug with it.

This issue still reproduces with this.

(In reply to Stephen A Pohl [:spohl] from comment #11)

(In reply to Dave Townsend [:mossop] from comment #10)

I'll have to test this when I get home as it definitely seems to be triggered, or made much more likely by using an external monitor. Possibly why others aren't seeing it.

I have tested with external monitors as well, but still haven't been able to repro. What version of macOS are you using? And I'm assuming that you have "Displays have separate Spaces" selected in System Settings > Desktop & Dock, is this correct? Does it reproduce when this is switched off? You may have to log out and back in to change this setting.

I do run with "Displays have separate Spaces" selected however the issue still occurs without it. Note that when I have my external monitor connected my laptop is closed so I still only have one display.

Comment 13

[Stephen A Pohl]

Thanks for confirming. What version of macOS are you running?

Comment 14

[Dave Townsend [:mossop]]

(In reply to Stephen A Pohl [:spohl] from comment #13)

Thanks for confirming. What version of macOS are you running?

Version 15.2 (24C101)

Comment 15

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

Hey Stephen, any update on this? Thanks :-)

Comment 16

[Stephen A Pohl]

No update yet, unfortunately. Are you saying that you are experiencing this issue as well?

Comment 17

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

ahah no, I'm only helping out the release management team for v136 :-) Sorry for the confusion!
(I don't use MacOS so I can't check!)

We'd only want to know if this would be OK to keep the regression in v136 (like we did for v135). According to your comment 8 I would say it's OK, but it would be good to get your confirmation on that.

Comment 18

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1765391

Comment 19

[Stephen A Pohl]

I see, thank you. Yes, I still believe that it is better to keep this regression than to revert a patch that fixed 5 crashes. I also haven't heard more reports of users running into this issue, so my hope is that this is rather rare. We discussed this issue during our weekly macOS Spotlight meetings and may revisit the entire menu bar handling altogether, which would address this bug as well.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

FWIW, 135 only shipped today, so now is about the point where I'd expect whether we'll find out how commonly this is being encountered in the wild.

Comment 21

[Andrew Overholt [:overholt]]

FWIW I can reproduce this quite frequently.

Comment 22

[Stephen A Pohl]

(In reply to Andrew Overholt [:overholt] from comment #21)

FWIW I can reproduce this quite frequently.

Thanks for letting me know! Is this using the same steps as :mossop? Or is there another way to reproduce?

Comment 24

[Andrew Overholt [:overholt]]

(In reply to Stephen A Pohl [:spohl] from comment #22)

(In reply to Andrew Overholt [:overholt] from comment #21)

FWIW I can reproduce this quite frequently.

Thanks for letting me know! Is this using the same steps as :mossop? Or is there another way to reproduce?

I don't do a lot of clicking on my desktop and I only use 1 workspace but switching windows seems to trigger it for me. I thought it might be related to me having the system dark/light theme set to auto but it appears not.

Comment 26

[Markus Stange [:mstange]]

Changing the bug summary from "invisible" to "looks inactive" - I think in mossop's case, the menu looks invisible because it's black text on top of a very dark desktop wallpaper. But really the menu is there, it's just super low contrast.

Comment 29

[Markus Stange [:mstange]]

I haven't had any luck reproducing this so far. I've made a try build with extra profiler markers - could you reproduce the bug with that build and capture a profile of it? Download target.dmg - run xattr -c target.dmg before mounting to get around macOS complaining that it can't verify it

Comment 30

[arekkusu]

I find this bug to be very easy to reproduce. My environment is:

M3 Max MacBook Pro, Sonoma 14.7.4. No external monitors.
System Settings > Appearance: Light.
Accessibility > Display > Increase Contrast √
Accessibility > Display > Reduce Transparency √
To reproduce:

1. launch Firefox 135.0
2. Cmd-Tab to Finder
3. Cmd-Tab to Firefox
4. repeat steps 2-3 as needed

This bug is intermittent, but generally reproduces within 3 or 4 Cmd-Tab switches. As such, I encounter it many dozens of times each day during my normal workflow.

See also other users: https://connect.mozilla.org/t5/discussions/menu-fonts-white/td-p/86233

Comment 31

[mjr]

2018 mac mini
Sonoma 14.6.1 (23G93)
System Settings > Appearance: Light.

I do not have the same Accessibility settings as @arekkusu.

My desktop background photo is black, which renders the macOS menu bar in white at the top.

I experience exactly this as well: "This bug is intermittent, but generally reproduces within 3 or 4 Cmd-Tab switches. As such, I encounter it many dozens of times each day during my normal workflow."

Though I've also experienced it less frequently on a new MacBook Pro, also still running Sonoma, similar settings.

Comment 32

[mjr]

(In reply to mjr from comment #31)

2018 mac mini
Sonoma 14.6.1 (23G93)
System Settings > Appearance: Light.

I do not have the same Accessibility settings as @arekkusu.

My desktop background photo is black, which renders the macOS menu bar in white at the top.

I experience exactly this as well: "This bug is intermittent, but generally reproduces within 3 or 4 Cmd-Tab switches. As such, I encounter it many dozens of times each day during my normal workflow."

Though I've also experienced it less frequently on a new MacBook Pro, also still running Sonoma, similar settings.

Forgot to mention that I am using an external monitor, in both cases.

Comment 33

[Steven Michaud [:smichaud] (Retired)]

Bug 1765391's crashes only happen on macOS 13 and below. Has anyone reproduced this bug on macOS 13 or below? If not, a quick and ready solution, though ugly, is to disable the fix for bug 1765391 on macOS 14 and above.

Comment 34

[Steven Michaud [:smichaud] (Retired)]

On an Intel MacBook Pro (MacBookPro16,1) I can pretty easily reproduce this bug using Cmd-Tab with Firefox 135.0.1 the only app running, but only on macOS 15 (15.3 and 15.3.1) and 14 (14.7.4). I can't reproduce it on macOS 13 (13.7.4).

No external monitor. No special settings (in Firefox or the OS).

Comment 35

[Dave Townsend [:mossop]]

(In reply to Markus Stange [:mstange] from comment #29)

I haven't had any luck reproducing this so far. I've made a try build with extra profiler markers - could you reproduce the bug with that build and capture a profile of it? Download target.dmg - run xattr -c target.dmg before mounting to get around macOS complaining that it can't verify it

Done: https://share.firefox.dev/3QxFUwP

Comment 38

[u769112]

Please fix this ASAP, this is very unprofessional. Such a Bug should never slip through!

Comment 40

[Markus Stange [:mstange]]

I haven't made much progress on this bug yet.

Dave's profile shows that nothing strange is going on from our side: We swap out the mainMenu when we lose focus and then we swap it back in when we gain focus. It's just that the swap-in happens slightly later now. I couldn't see any indication of multiple swap-ins racing each other, or setting the same menu twice, or anything like that. I don't currently have an explanation for why the menu would stay stuck in the inactive state after the delayed swap-in.

I still haven't been able to reproduce this locally but I need to spend more time actually trying different machines.

One thing I'd like to try as an experiment is to not do the swap-out when focus is lost, and to make PaintMenu a no-op if we're trying to set the same menu that's already set. Then the "lose focus + gain focus" scenario should end up not touching NSApp.mainMenu at all.

Comment 41

[arekkusu]

Still trivially reproduces in 136.0, just tapping Cmd-Tab a few times.

Comment 42

[Brad Werth [:bradwerth]]

Still debugging. The problem appears to be that any call to nsMenuBarX::Paint() sets the static NSApp menubar. There are at least two instances of nsMenuBarX and they fight over the privilege of who is setting the static NSApp menubar at any given moment. One instance triggers ::Paint asynchronously here, and the other instance triggers ::Paint asynchronously here.

I'm still debugging, but this is clearly not correct unless we have code assurances that only one of these menubars is going to be painted at a time -- and which one?

Comment 45

[Brad Werth [:bradwerth]]

I can't reproduce this consistently, and the form it takes with my local build is slightly different. In my local build, I can sometimes get the menubar to appear grayed out when switching back to the app, but then it appears normally after about 1 or 2 seconds. My theory is that setting NSApp.mainMenu is the point of failure. Not because it's wrong, but because something about where we are in the call stack is causing problems. I have built a patch that defers the setting of mainMenu to the runLoop, like so:

id menuToSet = mNativeMenu;
[[NSRunLoop currentRunLoop] performBlock:^{
  NSApp.mainMenu = menuToSet;
}];

Thus far, I have not been able to get a grey menu to appear. I am going to keep testing, and if it appears to be completely consistent, I'll put the patch up for review.

Comment 46

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #45)

Thus far, I have not been able to get a grey menu to appear. I am going to keep testing, and if it appears to be completely consistent, I'll put the patch up for review.

And then, just now, it did reproduce for me in the same way (grey menu, wait 1 or 2 seconds, normal menu), so this theory is incorrect.

Comment 47

[Brad Werth [:bradwerth]]

I noticed that my local build seemed to adjust the menubar in some way when switching back to the app. I took a recording and confirmed that Firefox is initially displaying the hidden window menubar (no Profiles menu), then setting the proper menubar via a call to windowDidBecomeMain.

Two theories:

1. My logging isn't sufficiently robust to capture the code path that sets the hidden window menubar when Firefox comes back into focus. I think I have it covered, so this is unlikely.
2. When switching away from Firefox, windowDidResignMain is triggered and the hidden window menubar is preserved for the next time the app is foremost.

I think theory #2 is most likely, and I think that means we need to find a better signifier than windowDidBecomeMain to set NSApp.mainMenu. Maybe there's a delegate method for the app itself becoming foremost. That delegate method should be setting the menubar instead of something associated with one of the app's windows. I'm going to explore this further.

Comment 48

[Brad Werth [:bradwerth]]

applicationWillBecomeActive seems promsing. I'll work on this.

Comment 49

[Brad Werth [:bradwerth]]

applicationDidBecomeActive (necessary for the notification object's mainWindow property to be set) seems to be sufficient to get the menubar to appear correctly before the window becomes main. I'll prepare a patch.

Comment 50

[Brad Werth [:bradwerth]]

Attachment: WIP: Bug 1941595: Make the Cocoa App Delegate responsible for setting the app's mainMenu.

This allows the app to set the mainMenu at the earliest possible
opportunity. This ensures that there is no "stale" menubar that is shown
from the last time the NSApp.mainMenu property was set, which typically
will be the hidden window menubar set when the window resigned main.

Comment 51

[Brad Werth [:bradwerth]]

Nope, with the patch applied, my screen recording captures one frame of grey menu. I'll keep working on this.

Comment 52

[Brad Werth [:bradwerth]]

Nearly there. My local build no longer gets a grey menubar. However, when switching back to the app, we get a flash of the old "hidden window" menubar (no Profiles menu) before the proper menubar appears. In part, that's because windowDidBecomeMain fires before applicationDidBecomeActive. I'll figure out a fix.

Comment 53

[Brad Werth [:bradwerth]]

Hmm... thought I had it, but there's a new side effect of flashing the Dock when the app becomes active. It must be that NSMenu.menuBarVisible also affects the Dock. I'll keep at it.

Comment 54

[Markus Stange [:mstange]]

(In reply to Steven Michaud [:smichaud] (Retired) from comment #33)

Bug 1765391's crashes only happen on macOS 13 and below.

Here's a search for all the crashes in nsMenuBarX::Paint over the last 6 months in all Firefox versions:

https://crash-stats.mozilla.org/search/?signature=%3DnsMenuBarX%3A%3APaint&product=Firefox&date=%3E%3D2024-09-10T17%3A16%3A00.000Z&date=%3C2025-03-10T17%3A16%3A00.000Z&_facets=install_time&_facets=version&_facets=address&_facets=moz_crash_reason&_facets=reason&_facets=build_id&_facets=platform_pretty_version&_facets=signature&_facets=useragent_locale&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-platform_pretty_version

It's showing me 4 crashes on macOS 14 and 3 crashes on macOS 15. While not zero, this count is indeed much much lower than the number of crashes on macOS 13, which is 550.

I support the idea of limiting bug 1765391's fix to macOS 13 and below, to give us more time to look for a proper fix.

Comment 55

[Brad Werth [:bradwerth]]

Attachment: Bug 1941595: Make nsMenuBarX paint into a sync call for macOS versions macOS 14 and later.

This is attempting to do an effective backout of Bug 1765391, which
added the PaintAsync method. That was the working part of that Bug, and
it was presumed to be the source of the grey/disabled appearance that
provoked this Bug. Unfortunately, local builds with this patch applied
still show the grey menubar behavior.

Comment 56

[Steven Michaud [:smichaud] (Retired)]

(In reply to Brad Werth [:bradwerth] from comment #55)

Created attachment 9472501 [details]
WIP: Bug 1941595: Make nsMenuBarX::PaintAsync into a sync method for macOS versions macOS 14 and later.

This is attempting to do an effective backout of Bug 1765391, which
added the PaintAsync method. That was the working part of that Bug, and
it was presumed to be the source of the grey/disabled appearance that
provoked this Bug. Unfortunately, local builds with this patch applied
still show the grey menubar behavior.

Are you sure the @available keyword's value changes according to which macOS version is running? It may have to do with the macOS version on which the binary (XUL) was built.

There's already an nsCocoaFeatures::OnVenturaOrLater() method that checks which version of macOS is running. You can use it as a template for a new nsCocoaFeatures::OnSonomaOrLater() method.

Comment 57

[Brad Werth [:bradwerth]]

Attachment: Bug 1941595: Only set NSApp.mainMenu when the app is active.

This seems to solve the problem of an "inactive" menu appearing when the
app is made foremost. However, it does have the unwelcome side effect of
the first appearance of the menubar flashing a menubar containing only
the app title.

Comment 58

[Markus Stange [:mstange]]

In my opinion the "make sync on macOS 14+" approach has a better advantage/disadvantage trade-off.

Comment 59

[Brad Werth [:bradwerth]]

(In reply to Markus Stange [:mstange] from comment #58)

In my opinion the "make sync on macOS 14+" approach has a better advantage/disadvantage trade-off.

As best I can tell, that doesn't work, though it should. A backout of changeset 1543feed065207594a549e9a0d2738e0c39e9d2c does not work, not in my testing. Your mileage may vary. If you have a replication case, I encourage you to try each of the 3 options and see if they fix the issue:

1. Backout 1543feed065207594a549e9a0d2738e0c39e9d2c.
2. Apply D241856 (sync on macOS 14+).
3. Apply D242071 (only set NSApp.mainMenu when the app is active).

Comment 60

[Markus Stange [:mstange]]

Hmm. This bug being a regression from bug 1765391 is the only hypothesis we have so far. What else could it be a regression from?

Even if the backout doesn't avoid the delayed paint, it might still avoid the "stuck inactive" bug.

Comment 61

[Dave Townsend [:mossop]]

(In reply to Brad Werth [:bradwerth] from comment #59)

(In reply to Markus Stange [:mstange] from comment #58)

In my opinion the "make sync on macOS 14+" approach has a better advantage/disadvantage trade-off.

As best I can tell, that doesn't work, though it should. A backout of changeset 1543feed065207594a549e9a0d2738e0c39e9d2c does not work, not in my testing. Your mileage may vary. If you have a replication case, I encourage you to try each of the 3 options and see if they fix the issue:

I've tried all three of these.

1. Backout 1543feed065207594a549e9a0d2738e0c39e9d2c.
2. Apply D241856 (sync on macOS 14+).

In both of these case I was no longer able to reproduce the issue despite a lot of attempts. Conversely I was able to easily reproduce the issue on a clean build.

3. Apply D242071 (only set NSApp.mainMenu when the app is active).

This also did not cause the issue to reproduce any more. However one thing to note with this is that a couple of times that I launched this version I hit bug 1812622 and in that case the macOS menu bar showed just the "Nightly" menu, none of the others. I couldn't see any other case where that happened though.

Comment 63

[Brad Werth [:bradwerth]]

(In reply to Dave Townsend [:mossop] from comment #61)

I've tried all three of these.

Thank you so much, that's very helpful. With this result, I agree with Markus that the best course of action is to land D241856.

Here's my no-so-well-reasoned explanation for what is going on: The real issue is that we should only be setting NSApp.mainMenu when the app is active. Getting that wrong is what's what is causing the menubar to appear in a strange state, either briefly, or until focus is lost again. Before Bug 1765391 landed, all the calls to nsMenuBarX::Paint() (which sets mainMenu) were done in the same event loop as the firing of both applicationDidResignActive and windowDidResignMain, when the app was still active. With the landing of Bug 1765391, which made those calls async, there was time for the app to become inactive and for the problem to trigger. My debug builds must have slightly different application and window delegate timing, such that even with a full backout or with D241856 applied, I was seeing temporary menubar discoloration, whether or not the calls were sync or async. Release/optimized builds may have tighter timing with the delegate methods such that everything happens in the same event loop, ensuring the app is still active.

Note that if this explanation is correct, then we are still potentially vulnerable to this Bug reappearing in a call to nsCocoaUtils::PrepareForNativeAppModalDialog(). I'm unclear on the timing of those calls, but if any of them could happen when the app is inactive -- very unlikely -- then I'd expect to see this again.

Anyway, since D242071 (which I think addresses the root cause of the problem) has side effects I haven't been able to fix, let's land D241856.

Comment 64

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/913871d0f259
Make nsMenuBarX::PaintAsync into a sync method for macOS versions macOS 14 and later. r=mac-reviewers,mstange

Comment 65

[Steven Michaud [:smichaud] (Retired)]

(In reply to Pulsebot from comment #64)

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/913871d0f259
Make nsMenuBarX::PaintAsync into a sync method for macOS versions macOS 14
and later. r=mac-reviewers,mstange

+void nsMenuBarX::PaintAsyncIfNeeded() {
+  if (nsCocoaFeatures::OnVenturaOrLater()) {
+    // Sync is safe enough on macOS 14 and beyond.
+    Paint();
+  } else {
+    // Needed for macOS 13 and earlier.
+    PaintAsync();
+  }
+}

This part of the patch is incorrect. As I said in comment #56 above (after I corrected my original mistake), and again in an inline comment, you'll need to write an nsCocoaFeatures::OnSonomaOrLater() method and call it instead of nsCocoaFeatures::OnVenturaOrLater().

Comment 66

[Markus Stange [:mstange]]

Oh, I should have noticed that no new nsCocoaFeature method was added.

Comment 67

[Markus Stange [:mstange]]

(In reply to Steven Michaud [:smichaud] (Retired) from comment #56)

Are you sure the @available keyword's value changes according to which macOS version is running?

Yes, @available checks the runtime version. https://developer.apple.com/documentation/xcode/running-code-on-a-specific-version#Require-a-minimum-operating-system-version-for-a-feature

Comment 68

[Steven Michaud [:smichaud] (Retired)]

(In reply to Markus Stange [:mstange] from comment #67)

(In reply to Steven Michaud [:smichaud] (Retired) from comment #56)

Are you sure the @available keyword's value changes according to which macOS version is running?

Yes, @available checks the runtime version. https://developer.apple.com/documentation/xcode/running-code-on-a-specific-version#Require-a-minimum-operating-system-version-for-a-feature

Not correct, Markus.

The document you reference says "Your app’s minimum deployment target defines the range of operating system versions your app supports." But the "minimum deployment target" is a build parameter.

We really do need an nsCocoaFeatures::OnSonomaOrLater() method.

The same is true for #available in Swift. I know this from my own personal experience.

Comment 69

[Markus Stange [:mstange]]

@available is not the minimum deployment target. @available is used so that you can conditionally use APIs that require a newer macOS version than the minimum deployment target.

Comment 70

[Markus Stange [:mstange]]

I do agree that Apple's docs would be clearer if they said "@available checks the version at runtime". But this part is relatively unambiguous: "Rather than require the latest system software for each app update, target one or two older operating system versions to give people time to transition gradually. When you implement features found only in the most recent operating system version, wrap your code with availability markers."

Comment 71

[Steven Michaud [:smichaud] (Retired)]

I still think you're wrong, Markus, and that we need to use nsCocoaFeatures::OnSonomaOrLater().

Please run some tests. I don't have time to do it myself.

Comment 72

[Siguza]

@available is a runtime check. It calls __isPlatformVersionAtLeast() from libclang_rt staticlib, see: https://godbolt.org/z/Gxnj777hb

You can find the source of the staticlib here: https://github.com/llvm/llvm-project/blob/5a668bdb98d6507626585cedbff0f18628ed7e5c/compiler-rt/lib/builtins/os_version_check.c#L276-L286

Comment 73

[Serban Stanca [:SerbanS]]

Backed out for causing causing bp-nu bustages in nsMenuBarX.mm.

• Backout link
• Push with failures
• Failure Log
• Failure line: /builds/worker/checkouts/gecko/widget/cocoa/nsMenuBarX.mm:519:7: error: use of undeclared identifier 'nsCocoaFeatures'

Comment 74

[Markus Stange [:mstange]]

(In reply to Steven Michaud [:smichaud] (Retired) from comment #71)

I still think you're wrong, Markus, and that we need to use nsCocoaFeatures::OnSonomaOrLater().

Please run some tests. I don't have time to do it myself.

You don't need to run tests because I have verified this in the past. I'm not in the habit of stating things as facts if I am not sure about them.

Here, maybe this will convince you: If you check the generated assembly for -[ToolbarWindow updateTitlebarShownAmount:] in Hopper, for example by loading objdir/widget/cocoa/Unified_mm_widget_cocoa1.o (rather than the entirety of XUL), you will find a call to ___isPlatformVersionAtLeast which corresponds to the @available check in ScreenHasNotch.

(In reply to Siguza from comment #72)

@available is a runtime check. It calls __isPlatformVersionAtLeast() from libclang_rt staticlib, see: https://godbolt.org/z/Gxnj777hb

You can find the source of the staticlib here: https://github.com/llvm/llvm-project/blob/5a668bdb98d6507626585cedbff0f18628ed7e5c/compiler-rt/lib/builtins/os_version_check.c#L276-L286

(I hadn't seen this reply when I wrote the reply to Steven above)

Nice, this should be even more convincing! Thanks!

Comment 75

[Steven Michaud [:smichaud] (Retired)]

Sorry guys, but I'm still right.

I saved @Siguza's test app as available.mm, then compiled it using clang -o available available.mm on macOS 15.3.1. It displayed "Sequoia" when I ran it on macOS 15.3.1, but also when I ran it on macOS 14.7.4 and 13.7.4.

The available binary doesn't reference __isPlatformVersionAtLeast() directly. It'll take a bit longer to tell whether or not it get's called (I'll need to write a HookCase hook library).

#include <stdio.h>

int main(void)
{
    if(@available(macOS 15, *))
    {
        printf("Sequioa\n");
    }
    return 0;
}

Comment 76

[Markus Stange [:mstange]]

You need to make sure the compiler knows about your minimum deployment target. If it defaults MACOSX_DEPLOYMENT_TARGET=<your current version>, then it's going to remove the check.

However, I'm not going to have another bug be derailed by a discussion like this. Steven, I'm happy to help you get to the right answer in the #macdev channel on Matrix. I want no further comments on this bug about it.

Comment 77

[Steven Michaud [:smichaud] (Retired)]

Markus, I've found the answer. Your comment about MACOSX_DEPLOYMENT_TARGET is irrelevant.

My problem is that I was actually compiling using gcc. When I used clang, __isPlatformVersionAtLeast() got called and @available behaved as you say.

Your comment about "derailing" was impolite, at the very least. So was your labeling my comments "off-topic" before you understood what I was saying. I would now be labeling my own comments "off-topic". But you had no business doing so before I actually got to the bottom of things.

Comment 78

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/125506d9f960
Make nsMenuBarX paint into a sync call for macOS versions macOS 14 and later. r=mac-reviewers,mstange

Comment 79

[Sandor Molnar[:smolnar]]

Backed out for causing build bustages

Backout link: https://hg.mozilla.org/integration/autoland/rev/08ab40732eb58a135268b1f73b554b7957464e60

Push with failures

Failure log -> ERROR - /builds/worker/checkouts/gecko/widget/cocoa/nsMenuBarX.mm:519:7: error: use of undeclared identifier 'nsCocoaFeatures'

Comment 80

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/85b141632fb2
Make nsMenuBarX paint into a sync call for macOS versions macOS 14 and later. r=mac-reviewers,mstange

Comment 81

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/85b141632fb2

Comment 82

[Dave Townsend [:mossop]]

The fix appears to work for me, I'm unable to reproduce in today's build.

Comment 83

[Steven Michaud [:smichaud] (Retired)]

It works for me, too.

Using today's mozilla-central nightly on my Intel MacBook Pro (MacBookPro16,1), I'm unable to reproduce this bug on macOS 14 (14.7.4) or 15 (15.3.1). And I'm unable to reproduce bug 1765391's crashes on macOS 13 (13.7.4) (using my STR from bug 1765391 comment #61).

Comment 84

[Brad Werth [:bradwerth]]

Finally landed a buildable fix. Sorry for the thrash.