802238 - Investigate if channel-specific update allows stuck funnelcake/partner users to update

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Chris AtLee [:catlee]]

From channel mtg today:

Is it possible to create an update targeted at our funnelcake/partner build users so that they're able to update? This assumes that their failure to update is due in some way to the fallback behavior.

Related to bug 774618.

Comment 1

[[e-mail] (:bhearsum)]

One way to do this is to force completes by creating null partial snippets for the broken users. Wouldn't be terribly difficult.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Unfortunately we effectively tried comment #1 already and it didn't help. That was for mac 14.0.1 users where partials would fail because of resigning MacOS/Contents/firefox. The proportion of 14.0.1 funnelcake13/14 users remaining a month after 15.0* shipped was 80%, while on windows where we had a partial it was 60%.

Some other ways we might do funnelcake
* remove the app.partner.mozillaNN pref from distribution.ini, which results in the update and blocklist channel staying as beta or release (so we avoid bug 774618). We lose the ability to track ADI, and to send a specific update to these folks if we do this. catlee suggests we might add override the update url with an additional query parameter to get updates back (some AUS changes required too)
* some sort of hotfix based approach. Mossop says you can put an extension into distribution/extensions/ and it'll be copied into the profile if the app version is changing (and presumably on new profile). That extension could then open a webpage (firstrun analog) and uninstall itself

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Better idea - We modify channel-prefs.js to set <channel>-cck-mozillaNN instead of <channel>, to keep update and blocklist functionality and dodge the channel mismatch which is behind bug 774618. Would have to leave the app.partner.mozillaN pref out of distribution.ini still, and a modification to the repacking script to change channel-prefs.js

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

Testing the idea in #3:

* took the funnelcake15 build catlee made for stub testing on beta
* modified distribution/distribution.ini to be:
# Partner Distribution Configuration File
# Author: Chris AtLee <[e-mail]>

[Global]
id=mozilla15
version=1.0
about=Funnelcake Oct 2012

[LocalizablePreferences]
startup.homepage_welcome_url="http://www.mozilla.com/%LOCALE%/%APP%/%VERSION%/firstrun/?f=15"
startup.homepage_override_url="http://www.mozilla.com/%LOCALE%/%APP%/%VERSION%/whatsnew/?oldversion=%OLD_VERSION%&f=15"

which leaves out
[Preferences]
app.partner.mozilla15="mozilla15"

* modified defaults/pref/channel-prefs.js to hold
pref("app.update.channel", "beta-cck-mozilla15");

* in a new profile, with NSPR HTTP logging I saw

0[220f140]: http request [
0[220f140]:   GET /update/3/Firefox/17.0/20121010150351/WINNT_x86-msvc/en-US/beta-cck-mozilla15/Windows_NT%205.1.3.0%20(x86)/mozilla15/1.0/update.xml?force=1 HTTP/1.1
0[220f140]:   Host: aus3.mozilla.org

0[220f140]: http request [
0[220f140]:   GET /blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/17.0/Firefox/20121010150351/WINNT_x86-msvc/en-US/beta-cck-mozilla15/Windows_NT%205.1/mozilla15/1.0/1/1/new/ HTTP/1.1
0[220f140]:   Host: addons.mozilla.org

which confirms that the channel is sent properly in update and blocklist pings

* helpfully 17.0b2 had just generated updates, so I swapped to the betatest-cck-mozilla15 channel. The partial to 17.0b2 applied without problems. Will try to see if fallback works properly ...

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

After disabling the service & background staging, and downloading the partial, I close Firefox and changed C:\Documents and Settings\mozilla\Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox fc\updates\0\update.status to 'failed: 6'. I got a dialog box saying 'The partial Update could not be applied. Firefox will try again by downloading a complete Update.', which is the expected UI in the vanilla build case. After hitting the OK button the complete d/l starts, so failover is working here and bug 774619 is avoided.

The complete succeeded, or if I failed both I got the 'please download manually' dialog.

so tl;dr - the plan works, we just need a change to the repack script to execute it.

Comment 6

[Robert Strong (they/them - no direct email)]

Since we don't cleanup a funnelcake install at some later point I think this is fine. Will we will still want or need bug 774619 for future funnelcake or partner builds?

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

I had just been thinking short term for stub funnelcakes, but we could consider using channel-prefs.js for all future partner repacks. Given we don't include that js file in mar files it seems fairly safe, except for the hypothetical case where we want to change channel and the fallback in AUS2 from foo-cck-bar to foo is forgotten. Can you think of any other risks ?

Comment 8

[Alex Keybl [:akeybl]]

If this can't be fixed on the RelEng side, Rob also suggested the possibility of changing from the funnelcake channel to the release channel as part of an add-on hotfix. That may be a good Plan B.

Comment 9

[Robert Strong (they/them - no direct email)]

This bug and / or bug 774618 would fix new funnelcake clients. What I was referring to was setting a default pref in the add-on hotfix to override the partner settings so existing clients no longer experienced the bug that might be preventing them from updates.

Comment 10

[Nick Thomas [:nthomas] (UTC+12)]

Can we send hotfix's to partner builds specifically ? Mossop says we get hotfix addons via ping to versioncheck.a.m.o, which leads me to

extensions.update.url
https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%

extensions.update.background.url
https://versioncheck-bg.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%&currentAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE%
(those are the values for latest Nightly)

Those don't appear to include any channel or partner information so hard to see how me might distribute a hotfix without a lot of collateral damage to users we didn't want to touch.

Comment 11

[Chris AtLee [:catlee]]

Could the hotfix self-destruct if it's installed on a vanilla build?

Comment 12

[Robert Strong (they/them - no direct email)]

It can detect whether we have the additional prefs that come from distributions.ini and then do the right thing.

Comment 13

[Chris AtLee [:catlee]]

I think we figured out what we wanted here. Please open a new bug if we want to implement any of the suggestions here.