In bug 1787619, we handled a locked primary password (which prevents sync) by re-using the sync error state. While strictly true, the We’re having trouble syncing message there could be more specific in this case.

@Sam -- Could you clarify the difference btwn this bug and the one you reference above?

(In reply to Ray Fambro from comment #1)

@Sam -- Could you clarify the difference btwn this bug and the one you reference above?

Yeah, this is a suggestion to have some more specific wording in our error panel. Right now we show the generic "We’re having trouble syncing" / "Firefox can't reach the syncing service right now. Try again in a few moments." If the reason we can't sync is because the user needs to unlock their primary password, waiting isn't going to help. clicking the "Try again" button will re-prompt them to unlock with their primary password - so we can show a better message here.

Got it! Flagging Phil for assistance here as I agree that we could use a more specific message. Not considering this as a blocker to ship, so can be follow up work.

@Sam I have a few questions to clarify:

1. This error occurs after the user has done something to lock the primary password; is there a state in which their primary password is already locked on first visit? I'm asking to determine if Firefox will know the primary password is locked on first visit (do we need to display primary password is locked on first visit, thus requiring more context).

2. Is there a need to update the "whoops that didn't work" message? If I fail to unlock my primary password, will the user receive the same error again?

I think that's all I have here, but let me know and I can make a clearer message.

(In reply to pbothun from comment #4)

1. This error occurs after the user has done something to lock the primary password; is there a state in which their primary password is already locked on first visit? I'm asking to determine if Firefox will know the primary password is locked on first visit (do we need to display primary password is locked on first visit, thus requiring more context).

The primary password prompt shows up automatically when sync needs your fxA login to authenticate. In most cases that will happen before the user gets to fx-view. We see this error if the user has primary password enabled but has prevented sync authenticating by failing to unlock. If landing on fx-view is the first thing that triggers sync needing to authenticate, then the prompt will automatically appear without any further user interaction. The error state only occurs if authentication fails due to primary password not having been unlocked. I'm not sure if that answers your question?

2. Is there a need to update the "whoops that didn't work" message? If I fail to unlock my primary password, will the user receive the same error again?
   I don't think we need a "didn't work" message. If they enter the wrong primary password, the prompt will just keep re-appearing until they either get it right, or cancel. If they cancel, they will be back in the same state, so I think showing the same message again is fine.

(In reply to Sam Foster [:sfoster] (he/him) from comment #5)

(In reply to pbothun from comment #4)

1. This error occurs after the user has done something to lock the primary password; is there a state in which their primary password is already locked on first visit? I'm asking to determine if Firefox will know the primary password is locked on first visit (do we need to display primary password is locked on first visit, thus requiring more context).

The primary password prompt shows up automatically when sync needs your fxA login to authenticate. In most cases that will happen before the user gets to fx-view. We see this error if the user has primary password enabled but has prevented sync authenticating by failing to unlock. If landing on fx-view is the first thing that triggers sync needing to authenticate, then the prompt will automatically appear without any further user interaction. The error state only occurs if authentication fails due to primary password not having been unlocked. I'm not sure if that answers your question?

2. Is there a need to update the "whoops that didn't work" message? If I fail to unlock my primary password, will the user receive the same error again?
   I don't think we need a "didn't work" message. If they enter the wrong primary password, the prompt will just keep re-appearing until they either get it right, or cancel. If they cancel, they will be back in the same state, so I think showing the same message again is fine.

I've made two slight variations to the error message based off of what I think is happening. The source of truth is in Figma, but below are plain text versions.

Option 1
Headline: Log back into your Firefox Account
Body text: Firefox is not able to sync tabs between devices until you re-enter your Firefox Accounts password.
CTA: Login

Option 2
Headline: Enter your password to get started
Body text: To grab your tabs, you’ll need to enter your Firefox Accounts password.
CTA: Enter password

Sam, let me know if either of these is more accurate to the error. I believe that Option 2 is more accurate, though I'm not sure.

Ray, I'll ping you and Flod in the Figma for feedback, but an update here would be good too.

(In reply to pbothun from comment #6)

Option 1
Headline: Log back into your Firefox Account
Body text: Firefox is not able to sync tabs between devices until you re-enter your Firefox Accounts password.
CTA: Login

Option 2
Headline: Enter your password to get started
Body text: To grab your tabs, you’ll need to enter your Firefox Accounts password.
CTA: Enter password

Neither of these is quite right. The user needs to unlock their primary password to proceed. In this case we aren't able to decrypt the user's FxA password because they've enabled primary password and cancelled a previous prompt to unlock it.

Apologies for the delay Phil. Sam is correct though. I left a comment in the Figma file.

@Sam -- Here is the updated Copy. Let me know if you see any issues with this.

https://www.figma.com/file/SE4xHgOW84yLiv7vFugm9R/Firefox-View-Stepping-Stone?node-id=13419%3A150168

(In reply to Ray Fambro from comment #9)

@Sam -- Here is the updated Copy. Let me know if you see any issues with this.

https://www.figma.com/file/SE4xHgOW84yLiv7vFugm9R/Firefox-View-Stepping-Stone?node-id=13419%3A150168

I replied in the figma file. That sounds fine to me. We have a day or so to get this new string into 107. I don't expect we can prepare a patch and get it landed in time for string freeze and soft code freeze, but if its important would might be able to land a patch quickly with just the strings which would allow us to uplift a 2nd patch hooking it up a new error message next week? Or we can just target 108. WDYT?

We're right up against the string freeze for 107, so we'll target 108 for this one.

• Updated the error message to use the text here
• Updated the existing password test to verify the message contents

https://hg.mozilla.org/mozilla-central/rev/6081a6678595