1746517 - Add query parameter to manual update URL

Status: RESOLVED FIXED

(Toolkit :: Application Update, enhancement, P3)

Description

[Nick Rishel [:nrishel]]

First brought up in https://bugzilla.mozilla.org/show_bug.cgi?id=1730110, this query parameter should inform Bedrock that users are visiting the site through the manual download prompt. The prior suggested ?reason=manual-update was agreed on with Bedrock.

Comment 1

[Nick Rishel [:nrishel]]

Attachment: Bug 1746517 - Add query paramaters to signify link was clicked due to manual update for all builds. r=nalexander

Depends on D133946

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/773a64daa5f2
Add query paramaters to signify link was clicked due to manual update for all builds. r=nalexander

Comment 3

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/773a64daa5f2

Comment 4

[Alex Gibson [:agibson]]

Hi Nick,

Now that bedrock has this parameter we're noticing quite a high volume of Firefox users entering this flow, so we're looking at ways we could optimise things better to make the manual update process smoother (see: https://github.com/mozilla/bedrock/issues/11071).

One way we might approach this is to show people a custom template instead (e.g one that provides context, extra directions, SUMO help links etc), rather than just the regular download page. But first we want to make sure that we understand the full flow here, so we can provide the best possible UX.

A couple of questions you might be able to help with:

1. Is there an existing user flow diagram for what happens here? If not, can you please outline the steps that happen from someone trying to update, to landing on the bedrock page?
2. Is there anyway we can trigger this flow ourselves for testing?
3. Is this flow only for release Firefox users? What happens for people on pre-release builds?

Thanks

Comment 5

[Daniel Veditz [:dveditz]]

3. Is this flow only for release Firefox users? What happens for people on re-release builds?

It happens on different channels, too, with different targets. Hopefully ones that still exist!
https://searchfox.org/mozilla-central/search?q=%3Freason%3Dmanual-update

Comment 6

[Daniel Veditz [:dveditz]]

2. Is there anyway we can trigger this flow ourselves for testing?

1. make sure updates will fail (disconnect network or tweak the app update pref to something that will be 404)
2. change the pref app.update.download.attempts to 10 or more
3. wait for a background update (you could also shrink the interval by setting app.update.interval to 60 seconds; think it has to be done before Firefox starts up)

I can't find a pref for the update URL anymore (maybe we moved it to keep malware from tweaking it) so I guess you'll have to disconnect the network.

Comment 7

[Nick Rishel [:nrishel]]

Hi Alex,

Just as a preface this was an onboarding bug for me; I'm not intimately familiar with this area but I'll note what I know and bring this up in the weekly for follow up.

1. The user flow I'm aware of is that when an update fails to apply automatically, thus requiring manual intervention. This appears in the about page and iirc the settings "Firefox Update" section.
2. When testing I just found the switch statement which controls automatic vs manual selection and forced the check to choose manual. I triggered it via a local update server, but you could probably apply the same trick as above for "update available" and avoid the hassle.
3. It works for all channels. Note: the channels that no longer exist are reused elsewhere (aurora->developer).

Comment 8

[Robin Steuber (they/them) [:bytesized]]

(In reply to Daniel Veditz [:dveditz] from comment #6)

I can't find a pref for the update URL anymore (maybe we moved it to keep malware from tweaking it) so I guess you'll have to disconnect the network.

Yeah, we pretty much did exactly that. You can, however, use an enterprise policy to change the update URL. For example, I often drop this in distribution/policies.json on my Windows builds when I'm doing update testing.

{
  "policies": {
    "AppUpdateURL": "http://127.0.0.1:8000/update.xml"
  }
}

---

(In reply to Alex Gibson [:agibson] from comment #4)

1. Is there an existing user flow diagram for what happens here? If not, can you please outline the steps that happen from someone trying to update, to landing on the bedrock page?

There are a couple of ways that the manual update prompt can be shown. We can fail to check for updates too many times. We can fail to download an update too many times. We can fail to elevate our privileges to install the update too many times. Also, if the update that we downloaded fails to apply in certain ways, we will also show it.

2. Is there anyway we can trigger this flow ourselves for testing?

Depending on how "realistically" you want to trigger it, you have a couple of options. The instructions that :dveditz gives in Comment 6 are about the most realistic, unless you really want to increment app.update.download.attempts "realistically" by actually causing 10 failures in a row.

Or, going in the other direction, you can sacrifice realism for convenience slightly by using this command in the Browser Console instead of waiting for a background update in step 3:

Cc["@mozilla.org/updates/update-service;1"].getService(Ci.nsITimerCallback).notify(null);

Or, if you just want to see the manual update prompt and don't care about making it show up "realistically", running this in the Browser Console should show it:

Services.obs.notifyObservers(null, "update-error", "unknown");

Comment 9

[Paul [:pmac] McLanahan]

(In reply to Daniel Veditz [:dveditz] from comment #5)

3. Is this flow only for release Firefox users? What happens for people on re-release builds?

It happens on different channels, too, with different targets. Hopefully ones that still exist!
https://searchfox.org/mozilla-central/search?q=%3Freason%3Dmanual-update

I see an issue with some of these URLs:

The ones in browser/branding/official/pref/firefox-branding.js don't have a trailing slash. This is fine, but it does result in an initial 301 to the final URL with the slash, but it does keep the query param.

$ curl-follow "https://www.mozilla.org/en-US/firefox/new?reason=manual-update"
HTTP/2 301
location: /en-US/firefox/new/?reason=manual-update
HTTP/2 200

Not sure it's worth filing a bug about, but FYI.