nodejs
fix: Wrong bitness information
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
- [x] I have read the Contributing Guidelines and made commit messages that follow the guideline.
- [x] I have run
npx turbo formatto ensure the code follows the style guide. - [x] I have run
npx turbo testto check if all tests are passing. - [x] I have run
npx turbo buildto check if the website builds without errors. - [x] I've covered new added functionality with unit tests if necessary.
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 |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
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 | ð |
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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?
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 :zzz: | 0 :x: | 0 :fire: | 4.444s :stopwatch: |
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
- What should we do if there is no official x86 support for a user with x86 architecture?
- 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.
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 ð
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
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
I hit this today too. Is the
;afterx64intentional?
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
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