1680516 - [Apple Chip - ARM64 M1] Game is not loaded on Gamearter.com

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Timea Cernea [:tbabos][inactive]]

Affected Versions:
84.0b7 - Beta - with or without Rosetta
85.0a1 (2020-12-03) - Nightly

Unaffected Versions:
83.0 - Release - works with Rosetta installed

Affected Platforms:
ARM64 MacOS on 3 different devices as follows:

• 2 DTK devices: MacOS Big Sur 11.0.1, Apple Development Platform, Chip: Apple a12z bionic, display 23-inch (1920 x 1080), with and without Rosetta
• 1 miniMac: MacOS Big Sur 11.0.1, Mac mini (M1, 2020), Chip: Apple M1, display 27-inch (2560x1440), without Rosetta

Unnafected Tested Platforms:
MacOS 10.15 MacBook Pro 13inch

Steps to reproduce:

1. Go to https://www.gamearter.com/game/fighter-aircraft-pilot
2. Proceed to play and skip the Ads
3. Wait for the game to download needed files

Expected Results:
The files should be downloaded so the game can be played.

Actual Result:
The files and never downloaded and the game cannot be played.

Severity suggestion: S3-S4, this is not a popular or demanded game to increase severity, but we don't know yet if other similar games could be affected or not.

Comment 1

[Haik Aftandilian [:haik]]

I can reproduce this on Beta84 and Nightly85 natively on an M1 MacBook Pro. It works for me under Rosetta.

Comment 2

[Haik Aftandilian [:haik]]

This also fails on Google Chrome 87 native. It works on Safari natively.

Comment 3

[Haik Aftandilian [:haik]]

This is a site issue caused by a known Unity bug which is now fixed in versions 2021.1.0a2 and above[1].

This game site is using Unity and the file UnityLoader.js has a regex checking for a version of macOS starting with 10.X which does not work when the macOS version is 11.0+ like Big Sur. The site works on our Intel builds on Big Sur because our Intel builds use an older SDK where the OS version reported by the OS is 10.16 instead of 11.X for compatibility. On Apple Silicon, we use the new 11.0 SDK and therefore the OS version is reported as 11.X and the user agent string is populated with 11.X which breaks the site.

Site operators need to update to newer versions of Unity or update the code in UnityLoader.js to use a regex that detects macOS 11.X. Alternatively, advanced users can workaround this problem by changing their user agent to include Mac OS X 10.16 instead of Mac OS X 11.0.

Changing the user agent (using a web extension) to use Mac OS X 10.16 instead of Mac OS X 11.1 worked around the problem for me with this game. New user agent I used with Firefox Nightly on Apple Silicon:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:85.0) Gecko/20100101 Firefox/85.0

1. https://issuetracker.unity3d.com/issues/unity-webgl-builds-do-not-run-on-macos-big-sur

Comment 4

[Chris Peterson [:cpeterson]]

(In reply to Haik Aftandilian [:haik] from comment #2)

This also fails on Google Chrome 87 native. It works on Safari natively.

Haik, why resolve this bug as invalid/wontfix instead of making Firefox's User-Agent string report macOS 11.0 as 10.16? Doesn't Safari report version 10.16?

We already spoof "Intel" on arm64 in the Firefox User-Agent string (bug 1655285) like Safari does (on macOS and iPadOS).

Comment 5

[Haik Aftandilian [:haik]]

(In reply to Chris Peterson [:cpeterson] from comment #4)

(In reply to Haik Aftandilian [:haik] from comment #2)

This also fails on Google Chrome 87 native. It works on Safari natively.

Haik, why resolve this bug as invalid/wontfix instead of making Firefox's User-Agent string report macOS 11.0 as 10.16? Doesn't Safari report version 10.16?

We already spoof "Intel" on arm64 in the Firefox User-Agent string (bug 1655285) like Safari does (on macOS and iPadOS).

@cpeterson, good point. We should definitely have x64 and arm64 return the same thing for the OS version, but I'm not sure about the compatibility implications of standardizing on 11.0 vs. 10.16. @spohl, do you have a recommendation on this?

On macOS 11.1 Beta,

Safari on arm64 native reports Intel Mac OS X 10_15_6.
Chrome on arm64 native reports Intel Mac OS X 11_1_0.

Comment 6

[Chris Peterson [:cpeterson]]

Here is the relevant code for the User-Agent string:

https://searchfox.org/mozilla-central/rev/1843375acbbca68127713e402be222350ac99301/netwerk/protocol/http/nsHttpHandler.cpp#1099-1106

#  elif defined(XP_MACOSX)
  SInt32 majorVersion = nsCocoaFeatures::macOSVersionMajor();
  SInt32 minorVersion = nsCocoaFeatures::macOSVersionMinor();

  // Always return an "Intel" UA string, even on ARM64 macOS like Safari does.
  mOscpu =
      nsPrintfCString("Intel Mac OS X %d.%d", static_cast<int>(majorVersion),
                      static_cast<int>(minorVersion));

Comment 7

[Haik Aftandilian [:haik]]

Regarding comment 5.

Comment 8

[Chris Peterson [:cpeterson]]

(In reply to Haik Aftandilian [:haik] from comment #5)

On macOS 11.1 Beta,

Safari on arm64 native reports Intel Mac OS X 10_15_6.
Chrome on arm64 native reports Intel Mac OS X 11_1_0.

Safari's User-Agent string has frozen the reported OS version at 10.15.x. On my x86 MBP running macOS 11.0.1 Big Sur, Safari 14.0.1 reports OS version Intel Mac OS X 10_15_6. Safari Technology Preview Release 116 (Safari 14.1) on the same machine, however, reports Intel Mac OS X 10_15_7.

Safari on Big Sur currently reports 10_15_6 because 10.15.6 was the latest Catalina version when Big Sur was released. Since then Apple has released a new Catalina security release 10.15.7. So the next version of Safari on Big Sur will bump its reported OS version to 10_15_7 so it doesn't report an older version than Catalina:

https://bugs.webkit.org/show_bug.cgi?id=217364

https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/mac/UserAgentMac.mm

Maybe now is an opportunity to freeze the macOS version we report in Firefox's User-Agent string?

Comment 9

[Chris Peterson [:cpeterson]]

Attachment: Bug 1680516 - Map macOS versions greater than 11.0 to 10.16 etc.

Comment 10

[Chris Peterson [:cpeterson]]

Attachment: Bug 1680516 - Cap the reported macOS version at 10.15 like Safari 14+ does.

Comment 11

[Chris Peterson [:cpeterson]]

Stephen and Haik, I posted two patches demonstrating two different approaches for your consideration:

1. Map macOS versions greater than 11.0 to 10.16 (and 12.0 to 10.17 etc).
2. Or freeze the macOS version at 10.15 like Safari 14+ does.

What do you think?

When Apple tried to freeze the entire User-Agent string back in 2017, some people pushed back, saying their companies used the macOS version in Safari's User-Agent string to warn their employees when they were using an old version of macOS. That sounds like a pretty niche use case for exposing the OS version fingerprint to the entire web. :)

https://twitter.com/ojaber/status/943566382159073280

Comment 12

[Stephen A Pohl [:spohl]]

We may want to involve folks with a bit more background in the history of UA strings, and where they're expected to go from here. Mike Taylor comes to mind, but maybe a new thread in dev-platform might make sense?

Comment 13

[Chris Peterson [:cpeterson]]

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

We may want to involve folks with a bit more background in the history of UA strings, and where they're expected to go from here. Mike Taylor comes to mind, but maybe a new thread in dev-platform might make sense?

Good idea. I can reach out to Mike Taylor, our Webcompat team, and dev-platform. Mike is on the Chrome team now, so he might have some additional perspective on the Chrome UA reporting version 11_0_1.

I was auditing the callers of nsCocoaFeatures::macOSVersionMajor() and nsCocoaFeatures::macOSVersionMinor() to make sure other callers didn't need to worry about macOS 11.0 Big Sur being reported as version 10.16 or 11.0 depending on the SDK Firefox was built with. If we decide to stick with 10.x version numbers, fixing up the version numbers inside the macOSVersionMajor() and macOSVersionMinor() functions (instead of in the UA string code) might avoid similar version number problems in other code.

Comment 14

[Sören Hentzschel]

If this Bugzilla ticket is now about the user agent difference between Intel and ARM then it's probably a duplicate of bug 1679929.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Karl, would it be possible to create a web compat intervention for this bug that we could ship in 84? It's unlikely we're going to get a product fix before 84 goes to release next week.

Comment 16

[Karl Dubost💡 :karlcow]

I'm checking with Dennis or Ksenia who has have bandwidth for this right now.

Comment 17

[Dennis Schubert [:denschub]]

Timea, could you test again with this build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GZ-URDQZQziS75eH1SFV3Q/runs/0/artifacts/public/build/target.dmg and see if it works with that?

Comment 18

[Timea Cernea [:tbabos][inactive]]

Can confirm the game is loaded using the provided build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/UbS0BNB4QyS_mAl30oOQEQ/runs/0/artifacts/public/build/target.dmg on the same M1 device.

Comment 19

[Dennis Schubert [:denschub]]

We decided against shipping this as a SAO update, and instead have the patches in bug 1682238 ride along in the next dot release. Cancelling my needinfo.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Fixed by way of a webcompat workaround as landed in bug 1682238. Added to to the Firefox 84.0.1 relnotes:

Fixed a bug causing some Unity JS games to not load on Apple Silicon devices due to improper detection of the OS version

Comment 21

[Timea Cernea [:tbabos][inactive]]

Confirming this as verified-fixed based on the verifications done for Bug 1682238.