Closed Bug 1792550 Opened 2 years ago Closed 2 years ago

Signing in to FxA with the primary password locked doesn't work correctly and leaves the user disconected.

Categories

(Firefox :: Firefox Accounts, defect, P1)

defect

Tracking

()

VERIFIED FIXED
107 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox105 --- unaffected
firefox106 --- wontfix
firefox107 --- verified

People

(Reporter: bmaris, Assigned: markh)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fidefe-2022-mr1-firefox-view])

Attachments

(2 files)

Found in

  • Firefox 106.0b4

Affected versions

  • Firefox 106.0b4
  • Latest Nightly 107.0a1

Tested platforms

  • Affected platforms: macOS 11.6, Windows 10, Ubuntu 18.04

Steps to reproduce

  1. Set up a primary password
  2. Restart Firefox
  3. Login to FxA
  4. Wait a bit and dismiss the primary password panel
  5. Go to Firefox View
  6. Click the Try Again button

Expected result

  • The primary password panel appears again.

Actual result

  • Nothing happens.

Regression range

  • This behaviour is from the time the Try Again button was implemented in Bug 1787619 so it is not a regression.

Additional notes

  • Here is the output from the console
Sync encountered an error - see about:sync-log for the log file. policies.js:975
1664277278438	FirefoxView.TabsSetup	DEBUG	tryToClearError: triggering new tab sync
1664277278438	FirefoxView.TabsSetup	DEBUG	Handling UIState update
1664277278439	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, conditions not met to exit state: : error-state
1664277278439	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, will notify update?:: true
1664277278439	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, in error state:: sync-error
1664277279060	FirefoxView.TabsSetup	DEBUG	Handling weave:service:sync:finish
1664277279060	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, conditions not met to exit state: : error-state
1664277279060	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, will notify update?:: true
1664277279061	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, in error state:: sync-error
1664277279062	FirefoxView.TabsSetup	DEBUG	Handling UIState update
1664277279062	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, conditions not met to exit state: : error-state
1664277279062	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, will notify update?:: true
1664277279062	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, in error state:: sync-error
1664277279372	FirefoxView.TabsSetup	DEBUG	tryToClearError: triggering new tab sync
1664277279373	FirefoxView.TabsSetup	DEBUG	Handling UIState update
1664277279373	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, conditions not met to exit state: : error-state
1664277279373	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, will notify update?:: true
1664277279373	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, in error state:: sync-error
1664277280175	FirefoxView.TabsSetup	DEBUG	Handling weave:service:sync:finish
1664277280176	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, conditions not met to exit state: : error-state
1664277280176	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, will notify update?:: true
1664277280176	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, in error state:: sync-error
1664277280177	FirefoxView.TabsSetup	DEBUG	Handling UIState update
1664277280177	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, conditions not met to exit state: : error-state
1664277280177	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, will notify update?:: true
1664277280177	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, in error state:: sync-error
1664277282560	FirefoxView.TabsSetup	DEBUG	tryToClearError: triggering new tab sync
1664277282561	FirefoxView.TabsSetup	DEBUG	Handling UIState update
1664277282561	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, conditions not met to exit state: : error-state
1664277282561	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, will notify update?:: true
1664277282561	FirefoxView.TabsSetup	DEBUG	maybeUpdateUI, in error state:: sync-error
Severity: -- → S3
Has STR: --- → yes
Version: other → Trunk

And here is the log from about:sync-log

Whiteboard: [fidefe-2022-mr1-firefox-view]
Priority: -- → P2
Blocks: firefox-view

Mark/Sammy, any idea what's happening here?

Flags: needinfo?(skhamis)
Flags: needinfo?(markh)
See Also: → 1792553

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #0)

  1. Go to Firefox View
  2. Click the Try Again button

Expected result

  • The primary password panel appears again.

Actual result

  • Nothing happens.

Over in bug 1792553 you have:

  • Go to Firefox View and click Try Again
  • Enter the correct primary password

Which seems to contradict this? (ie, this says no re-prompt, that reports a bug in what happens after a re-prompt)

switching needinfo to Sam who landed support for try-again re-prompting last week.

Flags: needinfo?(skhamis)
Flags: needinfo?(sfoster)
Flags: needinfo?(markh)

(In reply to Mark Hammond [:markh] [:mhammond] from comment #3)

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #0)

  1. Go to Firefox View
  2. Click the Try Again button

Expected result

  • The primary password panel appears again.

Actual result

  • Nothing happens.

Over in bug 1792553 you have:

  • Go to Firefox View and click Try Again
  • Enter the correct primary password

Which seems to contradict this? (ie, this says no re-prompt, that reports a bug in what happens after a re-prompt)

switching needinfo to Sam who landed support for try-again re-prompting last week.

The difference between the steps from bug 1792553 and the steps from this bug is that, in bug 1792553 I do a restart after logging into Firefox Accounts which makes the prompt appear.

Part of steps from bug 1792553:

  1. Login to FxA
  2. Dismiss the primary password modal (if prompted)
  3. Restart Firefox

(In reply to Bogdan Maris [:bogdan_maris], Release Desktop QA from comment #4)

The difference between the steps from bug 1792553 and the steps from this bug is that, in bug 1792553 I do a restart after logging into Firefox Accounts which makes the prompt appear.

Part of steps from bug 1792553:

  1. Login to FxA
  2. Dismiss the primary password modal (if prompted)
  3. Restart Firefox

But it has:
6. Dismiss the primary password modal (if prompted)
7. Notice that the user is still logged in to FxA
8. Go to Firefox View and click Try Again

So it still seems identical to me.

Regardless, I can't reproduce either of these bugs on a current Nightly - try again consistently re-prompts for a primary password, and things work correctly once it is entered, and works "as expected" when it is entered incorrectly (ie, continues to reprompt until canceled or entered correctly, and at no point can I see Firefox tell me FxA is disconnected.

Are you still able to repro on a new Nightly?

Flags: needinfo?(sfoster) → needinfo?(bogdan.maris)

Indeed, I can still reproduce this issue and the one from bug 1792553 using latest Nightly 107.0a1 (buildID: 20221003212025) from today. I used both a dummy account (guerrillamail) or a yahoomail account. Please let me know if I can help debug this if you still can't reproduce them.

Flags: needinfo?(bogdan.maris)

I also made a video on how I am able to reproduce this, the file is too large to upload it directly here so I uploaded it to Mozilla Gdrive: https://drive.google.com/file/d/1hcJ-v-J9Wom039SThKFxVdUbEgi0sMhO/view?usp=sharing

Ah, sorry for the confusion, I missed the critical part where you are logging in to fxa with the primary password locked. I'm surprised I can't find an existing bug for this, but it has existed forever. The problem is that we can't store the FxA credentials in this state, so Sync doesn't think it is logged in, and upon restarting we find no credentials in the login manager and force signing back in - this process will repeat until the user unlocks.

I think bug 1792553 should be closed as a dupe of this. A simple solution is probably to just cancel the signin process if the user declines to unlock.

Component: Firefox View → Firefox Accounts
Summary: Try Again from Firefox View does not prompt the primary password in a session once it has been canceled when login to FxA → Signing in to FxA with the primary password locked doesn't work correctly and leaves the user disconected.
Assignee: nobody → markh
Status: NEW → ASSIGNED

Mark, is this ready to land?

Flags: needinfo?(markh)
Severity: S3 → S2
Priority: P2 → P1
Pushed by mhammond@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/77055a1b1fc3
ensure the primary password is unlocked before signing in to sync. r=Mardak,sfoster
Flags: needinfo?(markh)
Severity: S2 → S3
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch

The patch landed in nightly and beta is affected.
:markh, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox106 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(markh)

:markh, is this bug important enough to require an uplift?

Gijs, I'm inclined to think we should not uplift this as it's not a trivial patch and the bug has existed for years - however, you might take a different view through a Firefox View lens - WDYT?

Flags: needinfo?(markh) → needinfo?(gijskruitbosch+bugs)

(In reply to Mark Hammond [:markh] [:mhammond] from comment #15)

:markh, is this bug important enough to require an uplift?

Gijs, I'm inclined to think we should not uplift this as it's not a trivial patch and the bug has existed for years - however, you might take a different view through a Firefox View lens - WDYT?

106 rc has been built already and this isn't important enough to respin RCs.

Flags: needinfo?(gijskruitbosch+bugs)
Flags: qe-verify+

Verified as fixed in our latest Beta 107.0b3, After setting a Primary password the user can no longer sign in to FXA without typing the Primary password first.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: