(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.
(In reply to Alex Gibson [:agibson] from comment #4)
- 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.
- 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:
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");