1695811 - Switch to a more relevant manual update URL

Status: NEW

(Toolkit :: Application Update, enhancement, P3)

Description

[Molly Howell (she/her) (no longer active)]

A part of the Proton project involved surveying the app update notifications, along with the other app menu notifications. UX pointed out in that process that the manual update URL we send users to in those notifications (the value of the app.update.url.manual pref) used to be more helpful than it is today, at least for the release channel (although we should take the opportunity to evaluate the other channels as well, including seeing whether ESR can be included). The current release URL is https://www.mozilla.org/firefox/ (with the build locale inserted), which is now a home page for the Firefox family and not just a landing page for the browser as it used to be, so it isn't ideal for this use.

Ideally I'd like to use https://www.mozilla.org/${AB_CD}/firefox/download/thanks/, which is linked directly from the current /firefox page and also specifically mentioned in the Bedrock documentation as being a direct download link (Bedrock being the name of the project which includes the mozilla.org site; the component mentioned there is used on at least a couple of pages, unfortunately neither of which is specific enough to be ideal for us to use here either). If there is concern about that URL being too internal to use from within the product, an alternative would be https://www.mozilla.org/${AB_CD}/firefox/new/, which is linked more broadly and is an improvement over what we have in that it includes a large download button, but isn't quite as good as /thanks because it requires clicking the download button without having really provided any instructions to do so, whereas /thanks automatically begins the download.

Comment 1

[Francesco Lodolo [:flod]]

Linking directly to that page is going to introduce issues for localization, and AFAIK the change was tabled for Proton pending further investigations.

By linking to download/thanks, the download will start automatically. But if the the page is not translated, you'll end up changing locale without realizing it.

Practical example:

• Firefox will try to reach uz/firefox/download/thanks for Uzbek (uz), but the page is not available. Bedrock will fall back to the next language in your accept-languages header, and ultimately to en-US.
  – While the page doesn't tell you anything about the locale you're downloading, if you end up in en-US/firefox/download/thanks you're going to download the en-US build without prompt.
• The download's name doesn't provide any information about the locale. You install it, and the locale of your build is suddenly changed.

Even the current solution is not ideal, because the download page doesn't clearly tell you which language you're downloading, and the link to other languages is pretty hidden. Ideally, we should download the build directly from CDN, since we know exactly which channel and locale the browser is using.

If the locale is unsupported in Bedrock, apparently we show a 404 page now (I think we used to have a redirect, but apparently that's not the case anymore (szl is an actual locale in Firefox, but it's riding the trains to release in 87)
https://www.mozilla.org/szl/firefox/download/thanks/

Comment 2

[Molly Howell (she/her) (no longer active)]

I'm removing the Proton tags from this bug because this has been removed from Proton's scope. I still think the bug is valid because the page we're using for this right now is not as helpful as it could be, but comment 1 and any other relevant localization issues should be taken into account before any patch is attempted; FWIW I do like the idea of directly downloading the right file instead of going through a web page at all, but if we do that then I think we need some in-product thing to tell the user what to do from there (a role that the download page currently fills).

Comment 3

[Mitchell Hentges [:mhentges] 🦀]

Attachment: Bug 1695811: Add Sentry secret scope to `mozilla-central`

mozilla-central jobs need to have access to the private
Sentry API key in order to use the sentry-cli.

Comment 4

[Phabricator Automation]

Comment on attachment 9211338 [details]
Bug 1695811: Add Sentry secret scope to mozilla-central

Revision D109661 was moved to bug 1698511. Setting attachment 9211338 [details] to obsolete.

Comment 5

[Mitchell Hentges [:mhentges] 🦀]

Sorry about that, mixed up my bug IDs :)