PlatformArch values support details

[rebloor]

Summary

As a result of [WebExtensions] Deprecate runtime.PlatformInfo.nacl_arch #43799, it was identified that a number of the PlatformArch values were missing. This PR adds those values.

To do

Confirm values supported in Safari.

Related pull requests

Content changes in mdn/content#43847.

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[bershanskiy]

I would prefer for MDN to just note that the enum values are strings but avoid describing the specific browser- and system-dependent values.

I'm not sure that PlatformArch enum values are relevant for MDN readers, especially since Google intentionally obscures the inner workings of the system (e.g., design docs for "multi-crx" feature not made public, including Chrome Updater and Chrome Web Store server-side code, manifest.json key "platforms"). Documenting the enum at any given point in time will not be effective in the long term since at any point someone can update Chromium source and forget to update MDN (e.g., to adding a value to avid crashes on one platform but not actually fixing the cause or even updating the tests).

runtime.getPlatformInfo() it does not appear to serve any real use case besides data collection for either fingerprinting or bug report triage (e.g., in uBlock Origin). This use cases do not require knowledge of enum values.

CC @oliverdunk Courtesy ping in case you would be interested in this discussion.

[Rob--W]

I would prefer for MDN to just note that the enum values are strings but avoid describing the specific browser- and system-dependent values.

If there values are mostly stable, there may be value in documenting examples of what they look like. An enum implies that the enumeration is complete. Since this is not true, we should note that the list may be incomplete, in the mdn/content side (e.g. as part of mdn/content#43847).

runtime.getPlatformInfo() it does not appear to serve any real use case besides data collection for either fingerprinting or bug report triage (e.g., in uBlock Origin). This use cases do not require knowledge of enum values.

An example of a use case that I can imagine for this information is when the extension wants to determine which binary to serve when asking users to install a native messaging application.

Documenting the enum at any given point in time will not be effective in the long term since at any point someone can update Chromium source and forget to update MDN (e.g., to adding a value to avid crashes on one platform but not actually fixing the cause or even updating the tests).

From the way you described it, it sounded like a senseless property was added to work around a crash without fixing a root cause. After reading the references you provided (they are the same, did you mean a different link?), I disagree with the "not actually fixing the cause" description. The issue there was that Chromium apparently started compiling (and running!) for a new platform which was previously unrecognized and therefore triggered the NOTREACHED assertion. Adding a new enum value is a reasonable way to deal with that. The non-crashing on such platforms provides "test coverage" for the correct working on that platform. What it unfortunately does not provide is the guarantee that the value continues to be supported in the long term (e.g. if the mechanism to determine the CPU changes).

Incidentally, Firefox uses the same riscv64 value, which also landed without unit tests (other than existing tests passing when run on that platform): https://bugzilla.mozilla.org/show_bug.cgi?id=1985988

On the Firefox side we document the supported build targets at https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html . Some of these targets are maintained by individuals external to the main project, which could call in question the long-term support of a particular architecture.

[bershanskiy]

If there values are mostly stable, there may be value in documenting examples of what they look like.

Perhaps, WECG should document the recognized values to avoid future incompatibilities like arm64 and aarch64?

did you mean a different link?

Yes, sorry for mistake, I updated the link in original comment.

From the way you described it, it sounded like a senseless property was added to work around a crash without fixing a root cause.

I'm sorry if he comment sounded a bit alarmist. This isn't a big deal really. The proper fix which we merged soon after was to make nacl_arch optional and fix the tests accordingly. There are still cases when arch can cause similar crashes on unsupported platforms and there we have three options: declare enum values for all CPU architectures in advance (e.g., rarely used MIPS, LoongArch, etc.), make compilation errors obvious (by adding #error statements), or make arch optional as well. I didn't create a CL implementing a fix yet because I could not choose one option out of the three.

Incidentally, Firefox uses the same riscv64 value, which also landed without unit tests (other than existing tests passing when run on that platform): https://bugzilla.mozilla.org/show_bug.cgi?id=1985988

Great! Can we document this in WECG? Can we fix discrepancy between arm64 and aarch64?

[rebloor]

Since this is not true, we should note that the list may be incomplete, in the mdn/content side (e.g. as part of mdn/content#43847).

Note added.

[Rob--W]

If there values are mostly stable, there may be value in documenting examples of what they look like.

Perhaps, WECG should document the recognized values to avoid future incompatibilities like arm64 and aarch64?

Incidentally, Firefox uses the same riscv64 value, which also landed without unit tests (other than existing tests passing when run on that platform): https://bugzilla.mozilla.org/show_bug.cgi?id=1985988

Great! Can we document this in WECG? Can we fix discrepancy between arm64 and aarch64?

Do you have an overview of the supported values across browsers? That would make it easier to tell what is different and what we should change or align on.

[bershanskiy]

If there values are mostly stable, there may be value in documenting examples of what they look like.

Perhaps, WECG should document the recognized values to avoid future incompatibilities like arm64 and aarch64?

Incidentally, Firefox uses the same riscv64 value, which also landed without unit tests (other than existing tests passing when run on that platform): https://bugzilla.mozilla.org/show_bug.cgi?id=1985988

Great! Can we document this in WECG? Can we fix discrepancy between arm64 and aarch64?

Do you have an overview of the supported values across browsers? That would make it easier to tell what is different and what we should change or align on.

We discussed it earlier here. I looked up the relevant source code and ran the following command in extension context:

JSON.stringify(chrome.runtime.PlatformArch, null, 2)

Google Chrome

"arm", "arm64", "mips", "mips64", "riscv64", "x86-32", "x86-64"

Source code

Link

{
  "id": "PlatformArch",
  "type": "string",
  "enum": [
    {"name": "arm", "description": "Specifies the processer architecture as arm."},
    {"name": "arm64", "description": "Specifies the processer architecture as arm64."},
    {"name": "x86-32", "description": "Specifies the processer architecture as x86-32."},
    {"name": "x86-64", "description": "Specifies the processer architecture as x86-64."},
    {"name": "mips", "description": "Specifies the processer architecture as mips."},
    {"name": "mips64", "description": "Specifies the processer architecture as mips64."},
    {"name": "riscv64", "description": "Specifies the processer architecture as riscv64."}
  ],
  "description": "The machine's processor architecture."
},

Note: Auto-generated ChromeOS runtime.d.ts is missing risc64.

Console output

{
  "ARM": "arm",
  "ARM64": "arm64",
  "MIPS": "mips",
  "MIPS64": "mips64",
  "RISCV64": "riscv64",
  "X86_32": "x86-32",
  "X86_64": "x86-64"
}

Firefox

"aarch64", "arm", "ppc64", "riscv64", "s390x", "sparc64", "x86-32", "x86-64", "noarch"

I believe official builds never return "noarch" value.

Source code

Link

{
  "id": "PlatformArch",
  "type": "string",
  "enum": [
    "aarch64",
    "arm",
    "ppc64",
    "riscv64",
    "s390x",
    "sparc64",
    "x86-32",
    "x86-64",
    "noarch"
  ],
  "allowedContexts": ["content", "devtools"],
  "description": "The machine's processor architecture."
},

Console output

{
  "AARCH64": "aarch64",
  "ARM": "arm",
  "PPC64": "ppc64",
  "RISCV64": "riscv64",
  "S390X": "s390x",
  "SPARC64": "sparc64",
  "X86-32": "x86-32",
  "X86-64": "x86-64",
  "NOARCH": "noarch"
}

Safari

"arm", "x86-64", "unknown"

I believe official builds never return "unknown" value.

Source code

Link

#if CPU(X86_64)
    static constexpr auto archValue = "x86-64"_s;
#elif CPU(ARM) || CPU(ARM64)
    static constexpr auto archValue = "arm"_s;
#else
    static constexpr auto archValue = "unknown"_s;
#endif

Console output

At the moment, I don't have access to my Safari machine.

[rebloor]

Updated as per @bershanskiy's feedback on supported values