This bug is to breakdown the UX for the sync migration *during the migration* - ie, once the user has opted to begin. Specifically, part of the migration process will require the user to create a FxA account and wait for verification. While we can open about:accounts to begin this process, we can't force the user to complete the process, and have no control over how long the notification email takes to arrive (if it arrives at all). Note that the browser might exit during this process - the browser could crash, the user could accept an upgrade notification, or the user may simply forget what they were doing. With the current thinking, the primary states the migration will be in are: * Offer accepted, waiting for signin to FxA account. We can open about:accounts, but must wait for the uer. * Signed in to FxA account, but waiting for it to be verified. We can't really do anything to help this along other than remind the user we are waiting. * Account verified, but waiting for us to upload the FxA account name for migration on subsequent devices. This doesn't require user interaction, but will depend on the state of the network and even our Sync infrastructure. * Waiting for the first FxA sync to complete Although once we are in this state we are effectively complete, so there may be no need to have any special UX in this state.

For new Sync.FxA registrants, we display an unverified state (really more of a pre-verified state): https://www.dropbox.com/s/gbhdffre8ztefq9/Desktop%20-%20Preferences%20-%20Sync%20-%20Unverified.pdf For migrating users, there is already syncing in place (legacy sync, see attached) Would we “freeze” legacy sync until the account is verified? (forcing them into the new sync?) If so, the Sync.FxA PDf above is probably all we need. Or would we allow the user to cancel/back out of the upgrade? If yes, the only change we'd need to make is to replace "Forget this email" with "Cancel", reverting to the old sync state. Thoughts?

The way I was thinking, and reading the PDF from bug 1014412, the sync dialog doesn't seem to come into it. IIUC, it looks something like: * An infobar tells the user they can upgrade, with a button to "join the party" (as the PDF puts it). * We then display about:accounts with the form filled with their email address Note that at this point we have a tab with about:accounts - no sync dialog. We are waiting for the user to perform the login. What UI is shown at this point? I was assuming the infobar would remain, but indicating something like "To continue upgrading sync, please login or create an FxA account". Note that at this point the user might close the browser (or it might crash). In that case, upon next startup we'd eventually get the new EOL notification from Sync - but instead of starting again, I'd assume the infobar goes back to where it was - "To continue upgrading sync, please login..." - presumably we'd them want a button to re-open about:accounts, and the infobar again stays open. * At some point the user then creates an account, but is waiting for verification At this point I'd assume the info bar remains, but now says "To continue upgrading sync, please check your email for a verification mail, and click the link". Again, at this point the browser might stop, and again, on restart we'd eventually want the infobar to reopen in the exact same state (ie, we don't want to reset and ask them to log back in - they already *are* logged in, just not verified) * Finally the user verifies, and we can finish the sync. At this point the infobar would probably say "Please wait while we complete the sync upgrade", and eventually the "now syncing" panel would open. The migration is now complete. At no point the Sync "options" pane opened. Obviously I might be missing something, but the above reflects my understanding of the general outline from bug 1014412.

I will flesh out the migration plan on Monday so it's ready for consumption into the cycle next week. Here is where we're at (LucidChart is back online). https://www.lucidchart.com/documents/view/e437f157-365a-4bdc-8f49-d76007559aa8

Adding myself to cc list because I suspect I'm going to wind up being the one to test all of this. Also taking QA Contact. Ryan et al, can we set up some time early next week to go over how you envision testing this stuff?

This is a UX bug, so there will be no output to test here - testing will need to occur in associated implementation bugs (e.g. bug 1019985 and related bugs).

Added to Iteration 33.1

Here is the most recent UX flow: https://www.lucidchart.com/publicSegments/view/53960efc-4b5c-484a-bcd5-13930a00de31/image.pdf The followup engineering bug: Bug 1038805