From the update verify logs for 3.7a5 --> 4.0b1 build1: Only in target/Firefox.app/Contents/MacOS/extensions: testpilot@labs.mozilla.com which is because the update.manifest in the complete mar's contains add-if "extensions/testpilot@labs.mozilla.com" "extensions/testpilot@labs.mozilla.com/chrome.manifest" add-if "extensions/testpilot@labs.mozilla.com" "extensions/testpilot@labs.mozilla.com/components/TestPilot.js" add-if "extensions/testpilot@labs.mozilla.com" "extensions/testpilot@labs.mozilla.com/content/all-studies-window.js" This is caused by a very ancient piece of code http://hg.mozilla.org/mozilla-central/file/9874f5c5cb63/tools/update-packaging/common.sh#l39 beltzner, Mossop - please confirm that TestPilot is supposed to be added on update, and we'll figure out a fix.

The complete updates are generated during the build using http://hg.mozilla.org/mozilla-central/file/FIREFOX_4_0b1_BUILD1/tools/update-packaging/common.sh#l39 The partial updates are generated separately using http://hg.mozilla.org/mozilla-central/file/UPDATE_PACKAGING_R11/tools/update-packaging/make_incremental_updates.py#l39 We could fix existing partials by unpacking them and repacking with a fixed copy of common.sh. You'd need dist/host/bin/mar for that. Otherwise we'd need to fix both code locations and respin.

Repacking partials obviously requires fixing the snippets too.

[ beware: plausible explanation lacking evidence follows ] We used to have the option of installing DOM Inspector and Talkback on Windows, which were placed in extensions/. We would have wanted to preserve those user choices when providing an update. The 'add-if' instruction in the update.manifest (and its pal 'patch-if') tell the updater to modify files if they are already present. So that's a mechanism to not add DOMi if it's not already there. Firefox 2.0 was the last branch to use optional installs (Talkback died, DOMi went to AMO) so code in comment #1 is just a left over that's now biting us. The fix is to switch to 'add' instructions. Note that any users who remove TestPilot will get it back on 4.0bN updates which use 'add'.

This would affect updates from the alpha users to the beta channel?

(In reply to comment #3) > [ beware: plausible explanation lacking evidence follows ] > > We used to have the option of installing DOM Inspector and Talkback on Windows, > which were placed in extensions/. We would have wanted to preserve those user > choices when providing an update. The 'add-if' instruction in the > update.manifest (and its pal 'patch-if') tell the updater to modify files if > they are already present. So that's a mechanism to not add DOMi if it's not > already there. This sounds very likely to be true to me. > Firefox 2.0 was the last branch to use optional installs (Talkback died, DOMi > went to AMO) so code in comment #1 is just a left over that's now biting us. > The fix is to switch to 'add' instructions. Note that any users who remove > TestPilot will get it back on 4.0bN updates which use 'add'. Users cannot uninstall it in the normal ways, they would have to delete the directory so I think that is fine.

(In reply to comment #4) > This would affect updates from the alpha users to the beta channel? Anyone updating that doesn't already have TestPilot would not receive TestPilot. cc'ing Thunderbird and SeaMonkey people since this change could affect them as well. How about just doing this for the Beta 1 update? If we offered an update from pre Beta 1 to Beta 2 they wouldn't get TestPilot but we could always (if we don't already) require updating to Beta 1 first by only offering the Beta 1 update snippet in the same way we only offer the latest minor on a release branch and only offer the major for the latest of a release branch. They would be able to remove TestPilot then without it reappearing.

(In reply to comment #6) > cc'ing Thunderbird and SeaMonkey people since this change could affect them as > well. We do have optional items in extensions/ in SeaMonkey, it would be nice not to lose this capability completely, though it might be a good idea to make that an option by itself.

(In reply to comment #6) > How about just doing this for the Beta 1 update? If we offered an update from I'm fine to lose the folks who jumped the gun on build 1 - we can relnote it or blog it or whatever.

Nick, are you ok with changing the add-if's for extensions (don't think the patch-if needs to be changed since these are all new files) for the Beta 1 update, only allow going to the Beta 1 update from the versions that will be offered the Beta 1 update (this way they will always get TestPilot), and then reverting the add-if's? This should take care of all scenarios.

I'm happy to repack the mar files for updates to 4.0b1. I don't think we need to ensure that the devpreviews always get b1 and then the latest release. If they don't update in the time it takes us to do 4.0b2 then lets not worry about them, we'll get a bigger increase in audience just from publishing 4.0b1.

Sounds good and thanks

Docs for fix: https://wiki.mozilla.org/Releases/Firefox_4.0b1/BuildNotes#Fix_snippets

And this for the mars https://wiki.mozilla.org/Releases/Firefox_4.0b1/BuildNotes#Repack_mar_files Done in opposite order, obviously.