Closed Bug 1680516 Opened 10 months ago Closed 9 months ago

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

Categories

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

ARM64
macOS
defect

Tracking

()

VERIFIED FIXED
86 Branch
Tracking Status
relnote-firefox --- 84+
firefox-esr78 --- unaffected
firefox83 --- unaffected
firefox84 + verified
firefox85 + verified
firefox86 + verified

People

(Reporter: tbabos, Assigned: cpeterson)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [necko-triaged])

User Story

This is a site issue for sites using older versions of Unity JS. Site operators should update to a fixed version of Unity JS. Alternatively, advanced users can change their user agent to include `Mac OS X 16.0` instead of `Mac OS X 11.0` until the sites have addressed the problem.

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

Per the Unity issue tracker, this is fixed in Unity 2021.1.0a2 and above.

Attachments

(2 obsolete files)

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.

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

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

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
Status: NEW → RESOLVED
Closed: 10 months ago
User Story: (updated)
Resolution: --- → INVALID
User Story: (updated)

(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).

Flags: needinfo?(haftandilian)

(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.

Flags: needinfo?(haftandilian)

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));

Regarding comment 5.

Flags: needinfo?(spohl.mozilla.bugs)

(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?

Assignee: nobody → 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

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?

Flags: needinfo?(spohl.mozilla.bugs)

(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.

Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Component: Graphics → Networking: HTTP
Severity: -- → S4
Priority: -- → P2
Whiteboard: [necko-triaged]

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

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.

Flags: needinfo?(kdubost)
See Also: → 1679929

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

Flags: needinfo?(kdubost)
Flags: needinfo?(dschubert)
Flags: needinfo?(timea.babos)
Flags: needinfo?(timea.babos)
Attachment #9191822 - Attachment is obsolete: true
Attachment #9191823 - Attachment is obsolete: true
Depends on: 1679929
See Also: 1679929

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.

Flags: needinfo?(dschubert)

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

Status: REOPENED → RESOLVED
Closed: 10 months ago9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch

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

Summary: [Apple Chip - ARM64 M1] Game is not loaded on https://www.gamearter.com/game/fighter-aircraft-pilot → [Apple Chip - ARM64 M1] Game is not loaded on Gamearter.com
You need to log in before you can comment on or make changes to this bug.