Bugzilla

I've found a simple fix for this bug:

https://hg.mozilla.org/try/rev/043ff153ec3adef98f7a1f52cff8cf8135f82935
https://treeherder.mozilla.org/jobs?repo=try&revision=6b2afeccd1b067a91b79cd6215dbfc50317ce53b

But it's moderately risky, and not perfect. So I'm going to hold off seeking a review until FF 86 is released. That way it'll have a long time to bake on the trunk and on beta.

As the [URL link for this bug](https://eclecticlight.co/2020/07/21/big-sur-is-both-10-16-and-11-0-its-official/) points out, the `SYSTEM_VERSION_COMPAT` environment variable can be used to control how the macOS version is reported to client programs on macOS Big Sur. If it's unset or set to `1`, the OS reports a "compatible" system version, which it reads from `/System/Library/CoreServices/SystemVersionCompat.plist`. But if `SYSTEM_VERSION_COMPAT` is set to `0`, or if the application from which the query takes place is built with the macOS 11 SDK, the OS reports the actual system version, which it reads from `/System/Library/CoreServices/SystemVersion.plist`.

The problem with the "compatible" version of macOS Big Sur is that it's always reported as "10.16" or "10.16.0", regardless of which minor version is running (11.0, 11.0.1, 11.1, 11.2 or 11.2.1). So in order to distinguish between these versions, we need to see the actual macOS version number, and not the "compatible" one.

Most code in the Mozilla tree doesn't need to make such fine-grained distinctions. So it'd be nice to arrange for only Crashreporter code to see the actual version number. But the `SYSTEM_VERSION_COMPAT` environment variable is read only once, very early in the application loading process (as `/usr/lib/libSystem.dylib` is initialized). So there's no point in changing its value once application code is running. And so the state of this environment variable (whether or not it's set, and what value it's set to) must be the same for *all* code in the `firefox` process and its child processes.

As best I can tell, there's no code in the tree which needs to be changed if the actual version number is reported (as opposed to the "compatible" one). I'll list this code (what I've been able to find) in a later comment. But, as far as I know, macOS version checking can happen in JS code and in extensions. It may even be possible to check the OS version from HTML code. So my patch has the potential to change the behavior of "client" code, outside of the Mozilla tree. So this patch should bake for a while on trunk and beta, to see if any problems arise. I'd also very much appreciate someone telling me how to do OS version checks from JS code (and if possible from HTML code). Then I can check the behavior in other browsers like Chrome and Safari.

Even without this workaround, though, the actual macOS version number will be reported to applications that are built with the macOS 11 SDK. So client code will eventually need to adapt to seeing actual version numbers (and not just compatible ones), as these applications become more common. So at worst my patch will only force them to adapt a bit earlier.

I mentioned above that this patch isn't perfect. It only works if Firefox is run from the GUI (by double-clicking on it, or by using `open` from the command line), and not by invoking the `firefox` binary directly (from the command line or otherwise). But I don't think this is a serious problem. The vast majority of users will open Firefox from the GUI. Those who don't will presumably be sophisticated enough to know that they need to set `SYSTEM_VERSION_COMPAT` explicitly, like so:

        SYSTEM_VERSION_COMPAT=1 /Applications/Firefox.app/Contents/MacOS/firefox

I've found a simple fix for this bug:

https://hg.mozilla.org/try/rev/043ff153ec3adef98f7a1f52cff8cf8135f82935
https://treeherder.mozilla.org/jobs?repo=try&revision=6b2afeccd1b067a91b79cd6215dbfc50317ce53b

But it's moderately risky, and not perfect. So I'm going to hold off seeking a review until FF 86 is released. That way it'll have a long time to bake on the trunk and on beta.

As the [URL link for this bug](https://eclecticlight.co/2020/07/21/big-sur-is-both-10-16-and-11-0-its-official/) points out, the `SYSTEM_VERSION_COMPAT` environment variable can be used to control how the macOS version is reported to client programs on macOS Big Sur. If it's unset or set to `1`, the OS reports a "compatible" system version, which it reads from `/System/Library/CoreServices/SystemVersionCompat.plist`. But if `SYSTEM_VERSION_COMPAT` is set to `0`, or if the application from which the query takes place is built with the macOS 11 SDK, the OS reports the actual system version, which it reads from `/System/Library/CoreServices/SystemVersion.plist`.

The problem with the "compatible" version of macOS Big Sur is that it's always reported as "10.16" or "10.16.0", regardless of which minor version is running (11.0, 11.0.1, 11.1, 11.2 or 11.2.1). So in order to distinguish between these versions, we need to see the actual macOS version number, and not the "compatible" one.

Most code in the Mozilla tree doesn't need to make such fine-grained distinctions. So it'd be nice to arrange for only Crashreporter code to see the actual version number. But the `SYSTEM_VERSION_COMPAT` environment variable is read only once, very early in the application loading process (as `/usr/lib/libSystem.dylib` is initialized). So there's no point in changing its value once application code is running. And so the state of this environment variable (whether or not it's set, and what value it's set to) must be the same for *all* code in the `firefox` process and its child processes.

As best I can tell, there's no code in the tree which needs to be changed if the actual version number is reported (as opposed to the "compatible" one). I'll list this code (what I've been able to find) in a later comment. But, as far as I know, macOS version checking can happen in JS code and in extensions. It may even be possible to check the OS version from HTML code. So my patch has the potential to change the behavior of "client" code, outside of the Mozilla tree. So this patch should bake for a while on trunk and beta, to see if any problems arise. I'd also very much appreciate someone telling me how to do OS version checks from JS code (and if possible from HTML code). Then I can check the behavior in other browsers like Chrome and Safari.

Even without this workaround, though, the actual macOS version number will be reported to applications that are built with the macOS 11 SDK. So client code will eventually need to adapt to seeing actual version numbers (and not just compatible ones), as these applications become more common. So at worst my patch will only force them to adapt a bit earlier.

I mentioned above that this patch isn't perfect. It only works if Firefox is run from the GUI (by double-clicking on it, or by using `open` from the command line), and not by invoking the `firefox` binary directly (from the command line or otherwise). But I don't think this is a serious problem. The vast majority of users will open Firefox from the GUI. Those who don't will presumably be sophisticated enough to know that they need to set `SYSTEM_VERSION_COMPAT` explicitly, like so:

        SYSTEM_VERSION_COMPAT=0 /Applications/Firefox.app/Contents/MacOS/firefox