Adding some relevant pointers - bug 1098694 in particular has information about the staging server and when it should hit prod

This doesn't quite work right. I tried various cases several times, and when "Choose what to sync" was checked, I usually did not get the customize.xul modal dialog after migration completed. "Usually" -- the first time I tried with "Choose what to sync" checked, I did get the dialog as expected. Every other time, I didn't. So there may be some race condition. First, what does work right: The "Choose what to sync" checkbox on the signup page is checked correctly depending on whether I had previously unselected any engines, the data of the "login" command received by aboutaccounts.js correctly contains a customizeSync bool, onLogin in aboutaccounts.js correctly sets the showCustomizationDialog pref, and needsCustomization() in browserid_identity.js correctly checks the pref. The problem is that once I click the verification email and Firefox sees that I've been verified, a whole bunch of services.sync.* prefs get set, or cleared maybe. At the same time, browserid_identity.js is going through the initializeWithCurrentIdentity flow. In every case after I started instrumenting the flow, services.sync.ui.showCustomizationDialog was cleared before browserid_identity.js examined it. I'm guessing that the one time where I got the customize.xul dialog as expected, it just so happened that showCustomizationDialog was cleared after browserid_identity.js examined it. Or maybe the whole bunch of prefs wasn't set/cleared that time, maybe because I used an old profile and/or and old Sync account. That was before I started instrumenting things and used new profiles and Sync accounts. I'm guessing the whole bunch of prefs being set/cleared is due to the prefs engine kicking in? I'll investigate more and file follow-up bugs as necessary.

(In reply to Drew Willcoxon :adw from comment #2) > I'm guessing the whole bunch of prefs being set/cleared is due to the prefs > engine kicking in? Oh, no. The bunch of prefs being set/cleared are things like services.sync.clients.lastRecordUpload, things that look like appropriate metadata. Not just a wholesale set/clearing of the sync.* branch. And I actually unchecked the prefs engine anyway. showCustomizationDialog is cleared by Weave.Service.startOver: http://mxr.mozilla.org/mozilla-central/source/services/sync/modules/service.js#909 Which is called by the migrator in _promiseCurrentUserState: http://mxr.mozilla.org/mozilla-central/source/services/sync/modules/FxaMigrator.jsm#238 So that's the race?

startOver both clears all the Sync prefs and triggers initializeWithCurrentIdentity, and the latter happens *serially* after the former -- no race condition at all. At least that's what I'm seeing. initializeWithCurrentIdentity has multiple callers, but I'm seeing it on startOver's stack when startOver accesses Status._authManager: http://mxr.mozilla.org/mozilla-central/source/services/sync/modules/service.js#931 (The _authManager getter then calls BrowserIDManager.initialize, which calls initializeWithCurrentIdentity.) Notice that that happens after the Svc.Prefs.resetBranch("") several lines above. So is this even a migration bug?

Closing this bug as I tested Sync engine selection after migration, with the result that it does not work when "Choose what to sync" is checked, and it needs to be fixed. I filed bug 1124956 to fix it.