Steps to reproduce:

1. Compile a local Firefox build with the 10.12 SDK.
2. Capture a profile in it.
3. Check the macOS version number that is displayed in the top left corner.

Expected results:
On macOS 12 Beta, you should see 12.0.0

Actual results:
In local builds, it says 10.16.0. https://share.firefox.dev/3gwbOYS
Regular Nightly seems to be fine.

This indicates that nsCocoaFeatures::GetSystemVersion gets the wrong version, which indicates that the contents of /System/Library/CoreServices/SystemVersion.plist are spoofed to contain "10.16" instead of "12.0".

Detecting the wrong version can cause various breakage; for example it'll break this check in IsAppRunningFromDmg().

I'm not sure why regular Nightly doesn't have this problem. Maybe the OS behaves differently based on the bundle name.

/System/Library/CoreServices/SystemVersionCompat.plist lists the ProductVersion as 10.16 -- exactly the same as on macOS 11. This means that nsCocoaFeatures::GetSystemVersion sees the system version as 10.16 when Firefox is run from the command line (again, exactly as on macOS 11).

But, as of bug 1690604, this doesn't happen when you run Firefox by double-clicking on its icon, or by using open /Applications/Firefox.app from the command line.

Mozilla should complain to Apple about this. Besides the workaround implemented at bug 1690604, there's not much we can do about it.

I got the same results in both the current Firefox release and today's mozilla-central nightly. I tested by doing about:crashparent, then looking at the crash report that was generated.

Ah indeed, starting from the command line was the difference! Thanks.

This will probably be fixed if we build with the macOS 11 SDK, would you agree? We can just do that.

This will probably be fixed if we build with the macOS 11 SDK, would you agree?

I don't know. You might need to build with the macOS 12 SDK :-(

I'll give it a try.

Actually, maybe building with the macOS 11 SDK will be enough. As far as I know the current Apple Silicon Firefox releases are all built with this SDK. But none of the crash reports on macOS 12 on Apple Silicon are recorded as "macOS 10.16.0" -- though many of them are on Intel hardware.

https://crash-stats.mozilla.org/search/?platform_version=~21A5268h&platform_version=~21A5284e&platform_version=~21A5294g&platform_version=~21A5304g&cpu_arch=arm64&date=%3E%3D2021-05-25T21%3A03%3A00.000Z&date=%3C2021-08-25T21%3A03%3A00.000Z&_facets=signature&_facets=platform_version&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-platform_version

https://crash-stats.mozilla.org/search/?platform_version=~21A5268h&platform_version=~21A5284e&platform_version=~21A5294g&platform_version=~21A5304g&cpu_arch=amd64&date=%3E%3D2021-05-25T21%3A03%3A00.000Z&date=%3C2021-08-25T21%3A03%3A00.000Z&_facets=signature&_facets=platform_version&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-platform_version

I built locally with the 11.1 SDK (that's the only 11+ SDK I had) and the build indeed now detects 12.0.0 when launched from the command line.

Setting initial priority and severity.

Now that the minimum SDK has been bumped to 11 in bug 1696504 I guess this can be closed?

Yup, this is fixed by bug 1696504.

... which got backed out.

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

... which got backed out.

Bug 1696504 landed again in 102.

mstange: This appears to still be broken. When running locally:

if (@available(macOS 10.15, *)) {
  printf("This should detect macOS 10.15\n");
}
if (@available(macOS 10.16, *)) {
  printf("This should detect macOS 10.16\n");
}
if (@available(macOS 11.0, *)) {
  printf("This should detect macOS 11.0\n");
}

 0:11.30 GECKO(57247) This should detect macOS 10.15
 0:11.30 GECKO(57247) This should detect macOS 10.16

My macOS version: 12.2.1 (21D62)
Processor: 2.4 GHz 8-Core Intel Core i9

I can work around this for implementing Bug 1782574, but there is a small amount of risk using raw values rather than named variables from macOS header files.

This is surprising to me. Since you're building with the 11.1 SDK (i.e. 11 or newer), I'd have expected @available(macOS 11.0, *) to work.
Stephen, can you take a look?

(In reply to Greg Tatum [:gregtatum] from comment #13)

mstange: This appears to still be broken. When running locally:

if (@available(macOS 10.15, *)) {
  printf("This should detect macOS 10.15\n");
}
if (@available(macOS 10.16, *)) {
  printf("This should detect macOS 10.16\n");
}
if (@available(macOS 11.0, *)) {
  printf("This should detect macOS 11.0\n");
}

 0:11.30 GECKO(57247) This should detect macOS 10.15
 0:11.30 GECKO(57247) This should detect macOS 10.16

My macOS version: 12.2.1 (21D62)
Processor: 2.4 GHz 8-Core Intel Core i9

I can work around this for implementing Bug 1782574, but there is a small amount of risk using raw values rather than named variables from macOS header files.

I'm unable to reproduce this. All three available checks get handled correctly and all three printf statements get executed, as expected. Greg, can you check your .mozconfig file to see if you have a path to a specific SDK set?

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

I'm unable to reproduce this. All three available checks get handled correctly and all three printf statements get executed, as expected. Greg, can you check your .mozconfig file to see if you have a path to a specific SDK set?

I missed your comment in #macdev that said that you didn't have this set in .mozconfig (or rather, that it was set to an 11.1 SDK). Does removing that line from the .mozconfig change anything for you?

Ah nice, removing the SDK override actually fixed it! I got the 11.0 check working.

This should detect macOS 10.15
This should detect macOS 10.16
This should detect macOS 11.0

Great!