Affected versions

• 67.0b13
• 68.0a1

Affected platforms

• Windows 10x64
• Ubuntu 18.04x64
• Windows 7x64

Steps to reproduce

1. Launch FF.
2. Create a new Sync account.
3. Confirm the selections screen.
4. Restart the browser.

Expected result

• The "Confirm your account" screen is still kept alongside the "Check your email" FxA doorhanger after browser restart.

Actual result

• The "Confirm your account" screen alongside the "Check your email" FxA doorhanger are no longer displayed after browsers restart

Regression range

• This issue is not a regression since it depends on feature implementation.

Additional notes

• Once the email is confirmed , the user is logged in automatically.

Vijay / Mark, can you investigate this and/or explain why this happens the way it does?

I suspect that this problem is tied to sync initialization. After restarting the browser and going to about:preferences?entrypoint=menupanel#sync, the unverified account is loaded and all the UX interfaces get the correct state.

Mark, does sync get initialized when there is an unverified account logged in? Or is it only when you have a verified account or browse to a sync page?

(In reply to Vijay Budhram from comment #2)

Mark, does sync get initialized when there is an unverified account logged in? Or is it only when you have a verified account or browse to a sync page?

No, it probably doesn't in the general case.

The problem here is in UIState.jsm - because there's not yet a services.sync.username preference it assumes sync isn't configured. We use that preference to avoid the initialization of FxAccounts - but that preference isn't set until we start syncing for the first time.

This impacts all of the sync UI for the browser, apart from about:preferences#sync as it uses FxAccounts directly. TBH, I'm not sure if the best approach here is to ensure that pref is set for an unverified user or to take the hit of initializing FxAccounts for non-sync users - probably the former, but we'll probably need to do extra work to ensure it is cleared if the user disconnects before verifying.

(I guess the "good" news is that this isn't a regression - the hamburger menu etc is the same - although I guess the new button makes it more obvious)

The priority flag is not set for this bug.
:markh, could you have a look please?

For more information, please visit auto_nag documentation.

I'm not sure exactly where this got fixed, but it now WFM.