fix: Wrong bitness information

[canerakdas]

Description

If we cannot get the user's bitness information from the userAgent if getHighEntropyValues is not supported, the default is x86.

We act as if we are using the architecture, but since the x86 version is not officially distributed for Linux and Mac, users are directed to the wrong links.

This PR aims to create an alternative source to getHighEntropyValues by adding more to the conditions we check in userAgent.

Also, should we do something in the UI for versions that do not have an x86 version? (Maybe disabling the button?) cc @nodejs/nodejs-website

Validation

It would be better to test it on as many operating systems as possible in preview 👀

Related Issues

Fixes #6360

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run npx turbo format to ensure the code follows the style guide.
• I have run npx turbo test to check if all tests are passing.
• I have run npx turbo build to check if the website builds without errors.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Mar 23, 2024 10:12am

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🟢 99	🟢 90	🟢 100	🟢 91	🔗
/en/about	🟢 100	🟢 91	🟢 100	🟢 91	🔗
/en/about/previous-releases	🟢 99	🟢 90	🟢 100	🟢 92	🔗
/en/download	🟢 99	🟠 89	🟢 100	🟢 91	🔗
/en/blog	🟢 100	🟢 90	🟢 100	🟢 92	🔗

[ovflowd]

Also, should we do something in the UI for versions that do not have an x86 version? (Maybe disabling the button?) cc @nodejs/nodejs-website

I thought we already disable x86 when x64 is not supported. But maybe it's because the initial state contains x86?

[github-actions]

Unit Test Coverage Report

Lines	Statements	Branches	Functions
	80.1% (451/563)	79.44% (143/180)	71.17% (79/111)

Unit Test Report

Tests	Skipped	Failures	Errors	Time
90	0 💤	0 ❌	0 🔥	4.444s ⏱️

[canerakdas]

In this PR, we prevent x64 Linux users from trying to download the x86 version, but two more issues come to my mind cc @nodejs/nodejs-website

1. What should we do if there is no official x86 support for a user with x86 architecture?
2. Arm or Apple silicon users who do not use the x64 platform and whose browser does not support getHighEntropyValues. There seems to be no problem since it is the only option on macOS. But I feel like we haven't been able to orient properly on Windows and Linux and need to do some development similar to what we did in this PR to figure out the architecture.

[canerakdas]

I thought we already disable x86 when x64 is not supported. But maybe it's because the initial state contains x86?

I couldn't get the question 🙈

[ovflowd]

I thought we already disable x86 when x64 is not supported. But maybe it's because the initial state contains x86?

I couldn't get the question 🙈

If the OS itself doesn't support x86 variants we should already disable prevent the state from reaching that. At least on the UI-side

The current bug is more related to the actual link generation

[ovflowd]

Arm or Apple silicon users who do not use the x64 platform and whose browser does not support getHighEntropyValues. There seems to be no problem since it is the only option on macOS. But I feel like we haven't been able to orient properly on Windows and Linux and need to do some development similar to what we did in this PR to figure out the architecture.

There's no much we can do. There's so much we can do with automated OS detection. I hope eventually Firefox supports these APIs

[sxa]

I hit this today too. Is the ; after x64 intentional?

Other than that, I definitely approve of this being fixed - and it works for me (TM) - but i the ; is an error then it should be fixed first.

[canerakdas]

I hit this today too. Is the ; after x64 intentional?

This is a bit of an edge-case scenario, some examples contain x64 in the user agent but whose architecture is not x64

For example, the user agent below;
Links (0.99; Darwin 10.7.0 i386; 236x64)

Architecture is i386 but it contains x64

As far as I understand from looking at this list, the x64; control is Firefox-based, but it is an added condition for what we cannot catch from other controls

[canerakdas]

The current bug is more related to the actual link generation

There seemed to be no problem with the current version of link generation 🤔

To make the code more understandable for everyone, I added comments and updated the default values for OS that do not support x86