Add Linux ARM64 button

[maureenlholland]

One-line summary

Update Linux download button group to show ARM64 option

Significant changes and points to review

Moved some standalone buttons to use the linux macro helper

• any reason we should revert to the standalones?

Updated download_button logic to show both linux options when OS is linux

• this only really makes sense to use with direct downloads, as it creates an extra click to go from a specific download button to /thanks page with the same specific download buttons
• updated release note buttons to use direct downloads

Issue / Bugzilla link

#648

Testing

I've used general.useragent.override set to Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 in about:config settings (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/User-Agent/Firefox#linux)

http://localhost:8000/en-US/channel/desktop/
http://localhost:8000/en-US/thanks/
http://localhost:8000/en-US/thanks/?xv=basic
http://localhost:8000/en-US/browsers/desktop/linux/

bottom section CTAs
release (/thanks link): http://localhost:8000/en-US/firefox/148.0beta/releasenotes/
beta (direct download links): http://localhost:8000/en-US/firefox/147.0/releasenotes/
esr (3 buttons, direct download): http://localhost:8000/en-US/firefox/128.12.0/releasenotes/

Available for testing on Demo 5: https://www-demo5.springfield.moz.works/en-US/browsers/desktop/linux/

[maureenlholland]

should I restrict this behaviour to only force direct if os is linux?

[janbrasna]

This currently links /thanks for release, and direct for other channels.

While on Linux the label says "for Linux 64-bit" the reality currently is that one still points to /thanks listing all the options anyways — so anything is an improvement over the current state, yeah. (I'd say for Release Notes stable channel, the text of the CTA ought to change, not its href destination — mainly for not showing the APT/RPM instructions there, only at the /thanks page…)

Rendering the repository note with the combo CTAs on the actual page could also be an option, but, TBH, I'm not sure if that only applies to release, or all channels in general? 🤷

(I don't know enough about attribution, but expecting this to not have an impact, esp. on other platforms, where I believe all these CTAs get the hash added to the bouncer link as well, so the utility of the /thanks scene used to be mainly for Windows as it had some more logic that I believe is no longer there [pinning to taskbar, setting as default etc.] so for now I think there's just the tendency to get rid of any custom logic and route things trough /thanks just for consistency mainly?)

[maureenlholland]

selector no longer exists, the button groups are using macro or download_firefox helper

[maureenlholland]

ported over from /browser/desktop/linux styles

[janbrasna]

Just a heads up — there will be additional RPM repo any day now (for Fedora and the like) so this won't be exclusive to Debian–style distros anymore. Maybe calling it

Suggested change

	.c-linux-debian {
	.c-linux-repository {

if that's available or something alike could ready that for further additions in advance. But it will/might need replacing across the whole site and tests anyways, so that's a separate task when time comes nonetheless.

[maureenlholland]

successful integration test run: https://github.com/mozmeao/springfield/actions/runs/20923551656 🟢

[janbrasna]

FYI I just quickly tried demo5 and apparently that one has very old product-details data according to https://www-demo5.springfield.moz.works/healthz-cron/ data-latest-firefox="143.0.4" which in turn gives funny results:

It's a neat corner case nonetheless. Wondering whether the macro should either only allow two of them, or align them better in case three versions exist?

[janbrasna]

"this only really makes sense to use with direct downloads, as it creates an extra click to go from a specific download button to /thanks page with the same specific download buttons"

This is fun. How come it never occurred to me before when testing the flows:/

Question is, the choice needs to stay in one place. What if that place is the /thanks scene only? So all the Linux buttons around the site, if they point to release, not other channels, probably should not break down the platforms or link directly — only /thanks should. (The /linux platform page is the only exception where the direct arch links are hard-coded I guess.)

The arch choices in the download macro only ever make sense for non-release channels, and their e.g. release notes CTAs — which are the ones that do not go through the /thanks page.

[maureenlholland]

re: outdated product details, good spot, we should update for demo but I don't think this is a corner case worth solving for, the three versions should only exist for ESR at the moment (which I think is only available on the download/all flow) - if we commonly expect three or more, moving to the dropdown as original issue suggested is probably the better approach

re: where to allow download vs direct to thanks page, this is my understanding of what would happen:

http://localhost:8000/en-US/channel/desktop/ => non-release, keep options
http://localhost:8000/en-US/thanks/ => the place to direct all release Linux buttons for final download choice
http://localhost:8000/en-US/browsers/desktop/linux/ => exception that shows direct download choice on non-thanks page

bottom section CTAs
http://localhost:8000/en-US/firefox/148.0beta/releasenotes/ => non-release, keep options
http://localhost:8000/en-US/firefox/147.0/releasenotes/ => release, direct to /thanks

@janbrasna let me know if that aligns with your thinking above or if I'm missing something

[janbrasna]

It's been a while and I must admit I never noticed there would be cases where the options end up presented for a consumer then directed to the thanks page for the same options again, so I apparently have not paid much attention to all the funnels and download flow variants.

However for the list of CTA occurrences above, I'd say yes that would be the ideal split, if it's worth the hassle special-casing direct vs. non-direct downloads based on the destination and/or channel, if the current macro functionality doesn't cover it well enough… (Given the choice would be on /thanks anyways so why not use it — At the same time, IIUC, the Linux downloads only get the list of platforms and the repository note on the /thanks scene, so if that's covered beforehand, it can equally skip the /thanks scene and link bouncer directly 🤷)

[janbrasna]

the three versions should only exist for ESR at the moment (which I think is only available on the download/all flow)

Oh, the button group for ESR downloads also renders on its ESR Release Notes page: https://www-demo5.springfield.moz.works/en-US/firefox/128.12.0/releasenotes/ (top & bottom) — so this appears to be a legit choice of archs, product-details data aside.

It should be the only occurrence of three architectures though, so I think while it's worth supporting this use case, perhaps with just some extra tlc for alignment — it's not necessary redoing that into a different component (as its 32bit option will also be temporary just for this year, and will go away most likely before Q4/26), would that be pragmatic enough @maureenlholland, wdyt?

[maureenlholland]

ESR Release Notes page:

oof, yeah, that needs to be handled. will apply alignment fix for this case, as suggested, thanks @janbrasna

[maureenlholland]

Demo 5 updated with latest changes. NOTE: product details has not been updated, it's a known issue around cron jobs timing out, not a blocker in this case, ticketed here: mozilla/bedrock#16899

[stephaniehobson]

One advantage of linking to the /thanks page is that it includes instructions for the APT repository.

I haven't dove in yet though so I'm not asking for changes.

[stephaniehobson]

Here's some screenshots from an actual Linux box from a user who browses in French:

[stephaniehobson]

Follow up questions (I'm sorry I'm having trouble figuring out the desired state by reading the thread):

• Should the 32bit version be an option for release (download/linux and /thanks)?
• Should we hide 32bit for non release channels? Or is that only showing because of the lagging product details?
• The ARM button isn't translated, I assume that's a lagging translation because I'm seeing English not a string ID but just double checking. Edit: confirmed by looking at code.
• Can we do anything about the wrapping download button?

The real solution here is to redesign /all and then link to a pre-filled Linux download page allowing the user to pick exactly what they want including APT instructions. Until then... Do we add a 4th button with the APT/SUMO link 😵‍💫?

[maureenlholland]

@stephaniehobson yeah, it's a rabbithole

Should we hide 32bit for non release channels? Or is that only showing because of the lagging product details?

For demo, I believe this is only due to lagging product details. Locally, it should not show the three buttons [edit: Two are expected everywhere with the exception of ESR, which still supports 32-bit]

Can we do anything about the wrapping download button?

Yep, that's a pretty straightforward style fix I think it's safe to bundle into this PR

Until then... Do we add a 4th button with the APT/SUMO link 😵‍💫?

I'd say no. I think in terms of iterative improvements, we can continue to leave anywhere that does not currently have an APT/SUMO link without an APT/SUMO link. It feels like an improvement to have the ARM64 option added for now.

[stephaniehobson]

R+ make sure the 32 bit buttons aren't showing on pre-release channels.

I think you've done the best you can with a bad situation. This is good until we can implement the real fix - redesigning /all.

[maureenlholland]

I can do wrapping style fix and final check on pre-release buttons Monday. As long as pre-release is confirmed, we can also do the style fix in a follow up PR and merge this week.

[maureenlholland]

this is all handled in the download-button styles, which are globally available (part of protocol.css stylesheet)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.27%. Comparing base (5288ea2) to head (b967cb7).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #897   +/-   ##
=======================================
  Coverage   81.27%   81.27%           
=======================================
  Files         119      119           
  Lines        6585     6585           
=======================================
  Hits         5352     5352           
  Misses       1233     1233           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[maureenlholland]

Adjusted to always show linux64 and linux ARM64 buttons when platform macros is used

[maureenlholland]

❌ I broke something re: Windows download button with last few commits: https://github.com/mozmeao/springfield/actions/runs/21357709708

Error: expect(locator).toBeVisible() failed

    Locator:  getByTestId('download-release-primary-win')
    Expected: visible
    Received: <element(s) not found>
    Timeout:  5000ms

    Call log:
      - Expect "toBeVisible" with timeout 5000ms
      - waiting for getByTestId('download-release-primary-win')


      53 |                     await expect(downloadButtonSecondaryWin).not.toBeVisible();
      54 |                 } else {
    > 55 |                     await expect(downloadButtonPrimaryWin).toBeVisible();
         |                                                            ^
      56 |                     await expect(downloadButtonSecondaryWin).toBeVisible();
      57 |                     await expect(downloadButtonPrimaryMac).not.toBeVisible();
      58 |                     await expect(downloadButtonSecondaryMac).not.toBeVisible();
        at /home/runner/work/springfield/springfield/tests/playwright/specs/products/firefox/firefox-release-notes.spec.js:55:60

Will have to return to this after higher priority tasks are finished

[maureenlholland]

successful test run: https://github.com/mozmeao/springfield/actions/runs/21593943390