Invite Debian-based distribution users to use Mozilla's .deb package instead of our current .tar.gz file #12966

JohanLorenzo · 2023-04-05T13:59:28Z

Description

Meta-bug: bug firefox-deb-repackage.
Additional context: FFXP-2363

In a few Firefox release cycles, the Release Engineering team will ship Firefox as a .deb package for Ubuntu and Debian users. Unlike we've always done so far, we won't redirect users to our latest binaries this time. Instead, we will display instructions on how they can set up their package manager to use our package. This is a standard practice in the Linux community (e.g.).

Timeline

We currently aim to get our first nightly users in Firefox 115 whose Nightly cycle starts a month from now. Depending the feedback we get from users, we may either ride the 115 train or let it bake in Nightly.

We plan to first announce it through Nightly's blog post (bug 1826540). So no need to have the nightly download page ready on the first day. That said, early in the 115 cycle would be appreciated.

Then, we can adjust the beta download page and then the release depending on the user feedback.

Expected behavior

The ultimate goal is to display the instructions (exhaustive list still to be determined) to Debian-based distribution users (e.g. users on Debian, Ubuntu, Linux mint). If we have a way to reliably detect the distro, then we should prevent these users from downloading the .tar.gz archive and show the instructions. If we have no easy way, then all Linux should see the instructions then confirm they want to download the .tar.gz anyway.

These changes should be reflected on the pages liked above as well as the main landing page. Instructions have to be localized too.

How does that sound to you all?

I'm happy to provide additional details.

Success Criteria

Let's agree on the right approach first, I'll be happy to define the success criteria afterwards 🙂

The text was updated successfully, but these errors were encountered:

alexgibson · 2023-04-06T09:23:32Z

@JohanLorenzo thanks for the heads up. Would it make sense to have the instructions as a SUMO page perhaps? Alternatively we could make a localized instructions page here on mozorg.

We can't detect specific distributions, but we do have existing logic to detect Linux as a general platform. We could use that to redirect people to an instructions page when they click a Firefox download link, instead of triggering a file download.

JohanLorenzo · 2023-04-06T10:00:13Z

Great idea! I hadn't thought of it. I see we already have this page on SUMO[1]. For sure, it will need to be updated. I agree it makes more sense to redirect Linux users to this page from bedrock, then!

~~@alexgibson, would you know who to ping to get a SUMO page changed?~~ Edit: I found this Bugzilla component with some names. I'll get started there 🙂

[1] https://support.mozilla.org/en-US/kb/install-firefox-linux

JohanLorenzo · 2023-04-06T12:31:02Z

I filed bug 1826748 for the SUMO request.

alexgibson · 2023-06-27T16:28:37Z

@JohanLorenzo just checking in here - is there anything you need us to do here still?

JohanLorenzo · 2023-06-28T09:55:45Z

Hey @alexgibson! Thanks for checking in! Yeah, we'll eventually need this change. That said, the timeline is not as clear as it was in April. The project got delayed because of a longstanding issue in Firefox. I'll get back to you once the schedule gets clearer again.

JohanLorenzo · 2023-12-11T14:04:32Z

@alexgibson 👋 I have some new info on the timeline. We are targeting Firefox 122 which goes to release on January 23rd. How does that sound to you?

alexgibson · 2023-12-11T14:16:01Z

@JohanLorenzo can you give an update on what's hoped for here on our side of things?

JohanLorenzo · 2023-12-11T14:24:24Z

So, if SUMO is the source of truth for instructions, then we should point Linux users there. Something like:

a Linux user wants to download Firefox
before downloading the tar.gz, we display a text like: "Using Debian, Ubuntu, or any Debian-based distribution? You can set up our APT repository instead."
a Linux should then choose which option to pick

Does that sounds okay? I don't have any strong preferences, I'm just getting the ball rolling 🙂

alexgibson · 2023-12-11T14:29:44Z

@JohanLorenzo can you please provide the SUMO URL you would like to link people to?

I'd like to try and get a little clearer on what's expected here if possible too. Is this correct?

A Linux user lands on http://www.mozilla.org/firefox/new/ and clicks download.
When redirected to http://www.mozilla.org/firefox/download/thanks/, instead of auto-starting the download, we instead display two options:
a. Link to SUMO for set up instructions
b. Link to download the tar.gz binary

Is that correct?

Is there any expectations for what should happen for Beta / Dev / Nightly?

sylvestre · 2023-12-11T14:30:29Z

I would like to see it here too:
https://www.mozilla.org/fr/firefox/all/#product-desktop-release
and having Debian/Ubuntu/Mint in the list ?

and redirect to the sumo page ?

alexgibson · 2023-12-11T14:31:07Z

I would like to see it here too:

What do you mean by "it"? Can you please be a bit more specific about what's expected?

sylvestre · 2023-12-11T14:32:40Z

something like this:

(adding a new item in the list)

JohanLorenzo · 2023-12-11T15:08:28Z

@JohanLorenzo can you please provide the SUMO URL you would like to link people to?

Okay, I just asked in bug 1826748#c4

JohanLorenzo · 2023-12-11T15:28:29Z

A Linux user lands on http://www.mozilla.org/firefox/new/ and clicks download.

When redirected to http://www.mozilla.org/firefox/download/thanks/, instead of auto-starting the download, we instead display two options:
a. Link to SUMO for set up instructions
b. Link to download the tar.gz binary

LGTM!

JohanLorenzo · 2023-12-11T15:35:48Z

Is there any expectations for what should happen for Beta / Dev / Nightly?

Could we do the same for Nightly and DevEdition? We mustn't do anything with Beta for now.

alexgibson · 2023-12-11T15:37:47Z

I'll make sure this gets on our team's radar, thanks all!

…x, and other Unix-like platforms. r=necko-reviewers,kershaw Freeze the CPU architecture reported in Firefox's `User-Agent` HTTP header and `navigator.userAgent` and `navigator.platform` Web APIs as `Linux armv81` on Android and `Linux x86_64` on Linux and other Unix-like platforms. Temporarily guard this change behind a pref so it can be disabled quickly, if needed. Goals: 1. Reduce fingerprintable entropy exposed to web content. 2. Reduce risk of webcompat problems from unexpected CPU architectures. Chrome's UA reduction effort made the same change in Chrome 107 (2022-10-25): https://www.chromium.org/updates/ua-reduction/#sample-ua-strings-phase-5. Firefox used to report the CPU architecture as "aarch64" on Android, but change to "armv81" to match Chrome and reduce the risk of future webcompat issues. For now, don't enable this pref for x86 Linux builds because Mozilla's Firefox download page checks the visitor's navigator.platform to determine whether to serve an x86 or x86_64 binary (or to direct users to a support page for other architectures, such as ARM64). If x86 and ARM64 Linux builds report they are "Linux x86_64", then the Firefox download pages will unknowingly serve those users an incompatible x86_64 binary. That issue will be resolved by Bedrock bugs mozilla/bedrock#12966 and mozilla/bedrock#14012. In the meantime, we can enable this pref in the meantime for ARM64 Linux (to fix YouTube bug 1869521 and webcompat issues like webcompat/web-bugs#130946) because Mozilla doesn't publish official ARM64 Linux builds of Firefox yet. These users are using unofficial or distro builds and presumably know not to attempt to download Firefox (using Firefox) from mozilla.org. Differential Revision: https://phabricator.services.mozilla.com/D197395

alexgibson · 2024-01-09T14:46:05Z

@JohanLorenzo circling back to this work. Is it OK for us to deliver the changes here any time after 122 ships?

JohanLorenzo · 2024-01-12T09:38:40Z

Discussed over Slack with @enavajas. We clarified the priority and agreed this ticket needs to ship at the same time as Firefox 122. Thank you folks for working on this! 😃

…x, and other Unix-like platforms. r=necko-reviewers,kershaw Freeze the CPU architecture reported in Firefox's `User-Agent` HTTP header and `navigator.userAgent` and `navigator.platform` Web APIs as `Linux armv81` on Android and `Linux x86_64` on Linux and other Unix-like platforms. Temporarily guard this change behind a pref so it can be disabled quickly, if needed. Goals: 1. Reduce fingerprintable entropy exposed to web content. 2. Reduce risk of webcompat problems from unexpected CPU architectures. Chrome's UA reduction effort made the same change in Chrome 107 (2022-10-25): https://www.chromium.org/updates/ua-reduction/#sample-ua-strings-phase-5. Firefox used to report the CPU architecture as "aarch64" on Android, but change to "armv81" to match Chrome and reduce the risk of future webcompat issues. For now, don't enable this pref for x86 Linux builds because Mozilla's Firefox download page checks the visitor's navigator.platform to determine whether to serve an x86 or x86_64 binary (or to direct users to a support page for other architectures, such as ARM64). If x86 and ARM64 Linux builds report they are "Linux x86_64", then the Firefox download pages will unknowingly serve those users an incompatible x86_64 binary. That issue will be resolved by Bedrock bugs mozilla/bedrock#12966 and mozilla/bedrock#14012. In the meantime, we can enable this pref in the meantime for ARM64 Linux (to fix YouTube bug 1869521 and webcompat issues like webcompat/web-bugs#130946) because Mozilla doesn't publish official ARM64 Linux builds of Firefox yet. These users are using unofficial or distro builds and presumably know not to attempt to download Firefox (using Firefox) from mozilla.org. Differential Revision: https://phabricator.services.mozilla.com/D197395 UltraBlame original commit: 8c2839bd6b4a48f0cff10be3a763cb8281a0a871

…x, and other Unix-like platforms. r=necko-reviewers,kershaw Freeze the CPU architecture reported in Firefox's `User-Agent` HTTP header and `navigator.userAgent` and `navigator.platform` Web APIs as `Linux armv81` on Android and `Linux x86_64` on Linux and other Unix-like platforms. Temporarily guard this change behind a pref so it can be disabled quickly, if needed. Goals: 1. Reduce fingerprintable entropy exposed to web content. 2. Reduce risk of webcompat problems from unexpected CPU architectures. Chrome's UA reduction effort made the same change in Chrome 107 (2022-10-25): https://www.chromium.org/updates/ua-reduction/#sample-ua-strings-phase-5. Firefox used to report the CPU architecture as "aarch64" on Android, but change to "armv81" to match Chrome and reduce the risk of future webcompat issues. For now, don't enable this pref for x86 Linux builds because Mozilla's Firefox download page checks the visitor's navigator.platform to determine whether to serve an x86 or x86_64 binary (or to direct users to a support page for other architectures, such as ARM64). If x86 and ARM64 Linux builds report they are "Linux x86_64", then the Firefox download pages will unknowingly serve those users an incompatible x86_64 binary. That issue will be resolved by Bedrock bugs mozilla/bedrock#12966 and mozilla/bedrock#14012. In the meantime, we can enable this pref in the meantime for ARM64 Linux (to fix YouTube bug 1869521 and webcompat issues like webcompat/web-bugs#130946) because Mozilla doesn't publish official ARM64 Linux builds of Firefox yet. These users are using unofficial or distro builds and presumably know not to attempt to download Firefox (using Firefox) from mozilla.org. Differential Revision: https://phabricator.services.mozilla.com/D197395 UltraBlame original commit: 8c2839bd6b4a48f0cff10be3a763cb8281a0a871

Fixes #14012 #12966

nathan-barrett · 2024-01-23T14:04:37Z

Closed as fixed in #14096

…4" in Linux User-Agent. r=necko-reviewers,kershaw This will match the behavior of ARM64 Linux (bug 1861847) and Chrome reporting their CPU architecture as "Linux x86_64": https://www.chromium.org/updates/ua-reduction/#sample-ua-strings-phase-5 Goals: 1. Reduce fingerprintable entropy exposed to web content. Few websites should need to distinguish 32-bit x86 Linux users from x86_64 Linux users. One of the few that did was Mozilla's own Firefox download page and it has now been updated to use distro packages instead of sniffing the UA string to offer Mozilla's architecture-specific installer binaries. (See bugs mozilla/bedrock#12966 and mozilla/bedrock#14012.) 2. Reduce risk of webcompat problems from websites not recognizing unexpected CPU architectures. (Example: in bug 1861847, YouTube treated ARM64 Linux as a mobile device) This "freezeCpu" pref controls this UA string code path: https://searchfox.org/mozilla-central/rev/1f27a4022f9f1269d897526c1c892a57743e650c/netwerk/protocol/http/nsHttpHandler.cpp#931-937 The UA string tests already check the "freezeCpu" pref to test for either "Linux x86_64" or the actual CPU architecture: https://searchfox.org/mozilla-central/rev/f602853ba8d55ba157e2a74d9b571615f6ed97b8/browser/components/resistfingerprinting/test/browser/browser_navigator.js#41-47,51 Differential Revision: https://phabricator.services.mozilla.com/D207238

alexgibson added this to Bedrock Technical Roadmap (2024) Dec 11, 2023

alexgibson moved this to Todo in Bedrock Technical Roadmap (2024) Dec 15, 2023

alexgibson mentioned this issue Dec 18, 2023

Remove CPU architecture detection for Linux #14012

Closed

2 tasks

alexgibson added the P2 Second level priority - Should have label Dec 18, 2023

nathan-barrett mentioned this issue Jan 16, 2024

Update linux flow on download-thanks #14096

Merged

alexgibson assigned nathan-barrett Jan 18, 2024

alexgibson moved this from Todo to In Progress in Bedrock Technical Roadmap (2024) Jan 18, 2024

nathan-barrett added a commit that referenced this issue Jan 23, 2024

Update linux flow on download-thanks (#14096)

f75443f

Fixes #14012 #12966

nathan-barrett closed this as completed Jan 23, 2024

github-project-automation bot moved this from In Progress to Done in Bedrock Technical Roadmap (2024) Jan 23, 2024

alexgibson mentioned this issue May 29, 2024

Improve Firefox download UI for Linux #14613

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Invite Debian-based distribution users to use Mozilla's .deb package instead of our current .tar.gz file #12966

Invite Debian-based distribution users to use Mozilla's .deb package instead of our current .tar.gz file #12966

JohanLorenzo commented Apr 5, 2023 •

edited

Loading

alexgibson commented Apr 6, 2023

JohanLorenzo commented Apr 6, 2023 •

edited

Loading

JohanLorenzo commented Apr 6, 2023

alexgibson commented Jun 27, 2023

JohanLorenzo commented Jun 28, 2023

JohanLorenzo commented Dec 11, 2023

alexgibson commented Dec 11, 2023

JohanLorenzo commented Dec 11, 2023 •

edited

Loading

alexgibson commented Dec 11, 2023

sylvestre commented Dec 11, 2023

alexgibson commented Dec 11, 2023

sylvestre commented Dec 11, 2023

JohanLorenzo commented Dec 11, 2023

JohanLorenzo commented Dec 11, 2023

JohanLorenzo commented Dec 11, 2023

alexgibson commented Dec 11, 2023

alexgibson commented Jan 9, 2024

JohanLorenzo commented Jan 12, 2024

nathan-barrett commented Jan 23, 2024

Invite Debian-based distribution users to use Mozilla's .deb package instead of our current .tar.gz file #12966

Invite Debian-based distribution users to use Mozilla's .deb package instead of our current .tar.gz file #12966

Comments

JohanLorenzo commented Apr 5, 2023 • edited Loading

Description

Timeline

Expected behavior

Success Criteria

alexgibson commented Apr 6, 2023

JohanLorenzo commented Apr 6, 2023 • edited Loading

JohanLorenzo commented Apr 6, 2023

alexgibson commented Jun 27, 2023

JohanLorenzo commented Jun 28, 2023

JohanLorenzo commented Dec 11, 2023

alexgibson commented Dec 11, 2023

JohanLorenzo commented Dec 11, 2023 • edited Loading

alexgibson commented Dec 11, 2023

sylvestre commented Dec 11, 2023

alexgibson commented Dec 11, 2023

sylvestre commented Dec 11, 2023

JohanLorenzo commented Dec 11, 2023

JohanLorenzo commented Dec 11, 2023

JohanLorenzo commented Dec 11, 2023

alexgibson commented Dec 11, 2023

alexgibson commented Jan 9, 2024

JohanLorenzo commented Jan 12, 2024

nathan-barrett commented Jan 23, 2024

JohanLorenzo commented Apr 5, 2023 •

edited

Loading

JohanLorenzo commented Apr 6, 2023 •

edited

Loading

JohanLorenzo commented Dec 11, 2023 •

edited

Loading