Closed Bug 1659655 Opened 4 years ago Closed 4 years ago

The PP prompt is displayed multiple times after dismissing the prompt twice on a form (on page load and form submit) if there are previously saved logins

Categories

(Toolkit :: Password Manager, defect, P1)

Desktop
Windows 10
defect

Tracking

()

VERIFIED FIXED
82 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 + wontfix
firefox81 + verified
firefox82 --- verified

People

(Reporter: rdoghi, Assigned: bdanforth)

References

(Regressed 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(3 files)

[Affected versions]:
Nightly 81.0a1 (2020-08-18)

[Affected platforms]:
Platforms: Mac OsX, Windows 10, Ubuntu

Steps :

  1. Launch the Firefox browser and have one set of credentials saved for www.facebook.com in about:logins
  2. Set up a Primary Password and restart the browser.
  3. Reach www.facebook.com and click cancel on the PP prompt.
  4. Enter a new set of credentials and Hit the Login button in order for the Primary Password prompt to be displayed.
  5. Click the Cancel button on the PP prompt.

Expected Results :
The Primary Password prompt should no longer be displayed after clicking the cancel button

Actual Results :
The PP prompt is displayed multiple times after Hitting the Cancel button.

Regression-Range:
Marking this as a regression introduced by Bug 1612258 for now. Please note that this might've been also a regression introduced by fixing Bug 1653945 or it was there but hidden behind it since Bug 1612258 was landed.
I can't reproduce it before Bug 1612258 got landed (mozregression also confirmed this).

Severity Suggestion:
Although it is not ok that we get multiple Primary Password prompts, this is reproducible only if the user cancels the Primary Password prompt 2 times:

  • once on page load
  • after submitting the form
    If the user types in the correct Primary Password the first or the second time when the prompt is displayed, this issue does not happen.
    Due to the above reasons, this seems like an edge case scenario, thus suggesting S3 Severity.

Hey Bianca, please take a look at this when you have the time. Thank you!

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(bdanforth)
Keywords: regression
Regressed by: 1612258
Summary: The PP prompt is displayed again after hitting the Cancel button → The PP prompt is displayed multiple times after dismissing the prompt twice on a form (on page load and form submit)

I can't reproduce it before Bug 1612258 got landed (mozregression also confirmed this).

I reproduced this locally on the parent commit to the commit for Bug 1612258, so I don't think this bug is a regression of Bug 1612258 (or any bugs that landed downstream, like Bug 1653945).

Could you try it one more time on the parent commit (i.e. the tip of mozilla-central before Bug 1612258 landed)?

Flags: needinfo?(bdanforth) → needinfo?(timea.babos)

Testing with BuildID:20200708214935 shows different results:
Reproducible on Windows 10 but not reproducible on MacOS 10.13 using the same steps and setup.

Flags: needinfo?(timea.babos)

(In reply to Timea Cernea [:tbabos] from comment #5)

Testing with BuildID:20200708214935 shows different results:
Reproducible on Windows 10 but not reproducible on MacOS 10.13 using the same steps and setup.

Just to clarify, this bug is reproducible on both Windows 10 and MacOS 10.13 in a recent Nightly, 81.0a1, but its reproducibility for BuildID 20200708214935 (the most recent Nightly build (80.0a1) without the patch for Bug 1612258) varies by OS:

  • The issue is reproducible on Mac OS 10.13
  • The issue is not reproducible on Windows 10

This makes it difficult to clearly identify a regression range for the bug, as it looks to differ by OS.

Timea, can you confirm that my understanding here is correct?

Flags: needinfo?(timea.babos)

Correct, I just checked it once more and I got the same results:

  • Reproducible on the latest Nightly (2020-08-20) on both MacOS and Windows 10.
  • Reproducible only on MacOS for the build without the patch for Bug 1612258.
Flags: needinfo?(timea.babos)
Assignee: nobody → bdanforth
Severity: -- → S3
Priority: -- → P3
Status: NEW → ASSIGNED

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Priority: P3 → P1

There are multiple root causes for the excessive Primary Password prompts. So far, none of the causes I have discovered are related to Bug 1612258, so I am going to remove that bug from the "Regressed By" field (though I can't yet explain why it does appear to be the regressing bug on Windows 10 only).

I am going to address the biggest root cause in this bug, and I will file another bug to fix the other known root cause and link it here tomorrow.

Regressed by: 1641413
No longer regressed by: 1612258
See Also: → 1660521
Summary: The PP prompt is displayed multiple times after dismissing the prompt twice on a form (on page load and form submit) → The PP prompt is displayed multiple times after dismissing the prompt twice on a form (on page load and form submit) if there are previously saved logins

QA verification notes

  • This fix covers most but not all excessive Primary Password prompts in this specific scenario.
  • There is at least one additional bug (Bug 1660521) that triggers the prompt every time the password save/update doorhanger is shown if there are previously saved logins for the site. That bug will be handled separately, as it is not a recent regression (it has a different root cause), and it should be considered out of scope here.
  • There may yet be another Primary Password prompt some time well after form submission in this scenario, but I could not reproduce it reliably to diagnose. If you are able to reproduce it, please file a separate bug for it and reference this one.
Flags: qe-verify+
Pushed by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3b754438cffa
Early return from LoginManagerPrompter._getUsernameSuggestions if Primary Password is locked. r=MattN
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch

Comment on attachment 9171307 [details]
Bug 1659655 - Early return from LoginManagerPrompter._getUsernameSuggestions if Primary Password is locked. r=MattN

Beta/Release Uplift Approval Request

  • User impact if declined: If the user:
  • has Primary Password enabled
    • Note: This feature is disabled by default.
  • has not authenticated for the current session
  • visits a login page with a saved login
  • cancels the expected Primary Password prompt on page load (from an attempt to autofill)
  • fills in and submits the form with a different login
  • cancels the expected Primary Password prompt on form submit (from an attempt to ask if the user wants to save this new login via a doorhanger)
    ...then the user will see several extra Primary Password prompts if they continue to cancel each one instead of authenticating successfully.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See STR in the Description and QA verification notes in comment #11.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): As described above, there are a specific set of conditions that must be met before the user would encounter this bug, so it only affects a small minority of users. The fix itself is very simple and only affects whether an autocomplete dropdown for the username field in the password save/update doorhanger shows or not.
  • String changes made/needed:
Attachment #9171307 - Flags: approval-mozilla-beta?

Comment on attachment 9171307 [details]
Bug 1659655 - Early return from LoginManagerPrompter._getUsernameSuggestions if Primary Password is locked. r=MattN

Approved for 81.0b4.

Attachment #9171307 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

This issue is Verified as Fixed in our latest Beta 81.0b4 as well as our latest Nightly build 82.0a1 (2020-08-30) on Windows 10 , Mac OSX and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

(In reply to Bianca Danforth [:bdanforth] from comment #11)

  • There may yet be another Primary Password prompt some time well after form submission in this scenario, but I could not reproduce it reliably to diagnose. If you are able to reproduce it, please file a separate bug for it and reference this one.

This happens only if Facebook recognizes the phony username as something similar to the users they have the database. In this case, after submitting the form Facebook will load a page with a suggested user along with a new form with username/password field. Thus, the Primary Password prompt will be displayed once again since a newly loaded form requires autofill permission from PP.
If this is what you encountered, it makes sense. If not, I will keep an eye out and see if we have other scenarios.

(In reply to Timea Cernea [:tbabos] from comment #18)

(In reply to Bianca Danforth [:bdanforth] from comment #11)

  • There may yet be another Primary Password prompt some time well after form submission in this scenario, but I could not reproduce it reliably to diagnose. If you are able to reproduce it, please file a separate bug for it and reference this one.

This happens only if Facebook recognizes the phony username as something similar to the users they have the database. In this case, after submitting the form Facebook will load a page with a suggested user along with a new form with username/password field. Thus, the Primary Password prompt will be displayed once again since a newly loaded form requires autofill permission from PP.
If this is what you encountered, it makes sense. If not, I will keep an eye out and see if we have other scenarios.

Thanks Timea; that is exactly the scenario, so that is not a bug, but expected behavior.

You need to log in before you can comment on or make changes to this bug.