1591181 - Unexpected placeholder "New login" credential added to sidebar after click View Saved Logins in password drawer (with no saved login)

Status: VERIFIED FIXED

(Firefox :: about:logins, defect, P1)

Description

[katieC]

Attachment: Screenshot_Lockwise_GhostCredential.jpg

STR:

1. Go to site with no saved login ex: 15Five.com
2. Click into password form + arrow down
       • Password form had no autofill (I hadn't actually saved this account)
3. Click View Saved Logins in dropdown/drawer
   • Opens Lockwise with no matches
4. Delete characters in search bar, back to "m" from "my.15Five.com"

Result: (please see screenshot)
• New Login at top of sidebar list with active language to enter credentials
• Main content ares has odd 1969 dates, Password button looks clickable...

Expected Result:

1. In Password Drawer on 15Five - I expect to see, "No saved logins found." and View Saved Logins button
2. When clicking "View Saved Logins" - I expect to see all of my saved logins, not a filtered search results with no matches

Comment 1

[Sam Foster [:sfoster] (he/him)]

Cosmin, can you see if this is a recent regression?

Comment 2

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Yes, it seems that this is a recent regression. The issue is not reproducible with an older Nightly 71.0a1 build from 2019-10-02.
Considering this, using mozregression tool I got the following results:

• Last good revision: 1cfb94153f548ea78f67e65478d6df36ecbfc14b
• First bad revision: 685cadf88d086be58c4808d68633680dfa4a1e53
• Pushlog: https://tinyurl.com/yyt7hu4t

It seems that one of the bugs from the pushlog introduced this issue. Unfortunately, I'm not sure which one introduced this behavior.

Comment 3

[Sam Foster [:sfoster] (he/him)]

(In reply to Cosmin Muntean, Experiments QA from comment #2)

It seems that one of the bugs from the pushlog introduced this issue. Unfortunately, I'm not sure which one introduced this behavior.

Thanks, that helps a lot.

Comment 4

[Matthew N. [:MattN]]

Mass removing [skyline] and [passwords:management] from about:logins bugs which are no longer useful.

Comment 5

[Pascal Chevrel:pascalc (PTO until April 26)]

Matt, this is marked as a P1 regression in 71 and jaws is on PTO, is that something that you or somebody else could work on or should the priority be lowered and mark it as wontfix for 71? Thanks

Comment 6

[Matthew N. [:MattN]]

I'll look into it. I'm guessing it's from this deletion: https://hg.mozilla.org/integration/autoland/rev/840a55a7b6d85e227e825dcc3e766ed752837180#l1.13

Comment 7

[Matthew N. [:MattN]]

Attachment: Bug 1591181 - Make the new-login-list-item @hidden by default. r=sfoster

Otherwise it will be selected as the visibleListItem and set as the @aria-activedescendant.

I confirmed that the test fails without the fix.

Comment 8

[Matthew N. [:MattN]]

Attachment: Bug 1591181 - Hide <login-item> whenever a login isn't selected even if there are search results. r=sfoster

I confirmed that the new test fails without the CSS change.

Depends on D51234

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c10e5c253cf3
Make the new-login-list-item @hidden by default. r=sfoster
https://hg.mozilla.org/integration/autoland/rev/518df4329a20
Hide <login-item> whenever a login isn't selected even if there are search results. r=sfoster

Comment 10

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/c10e5c253cf3
https://hg.mozilla.org/mozilla-central/rev/518df4329a20

Comment 11

[Pascal Chevrel:pascalc (PTO until April 26)]

Matt, do you think we can uplift it to beta or is it too risky and we should let it ship with 72? Thanks

Comment 12

[Simona Rosu [:srosu], Ecosystem QA]

I have verified this issue on the latest Nightly 72.0a1 (Build ID: 20191103213857) on Windows 10 x64, Mac 10.14, Ubuntu 16.04 x64.

• The “New Login” item is no longer displayed in the “Login List” after deleting the prepopulated filter from the search bar that returns 0 results.

Comment 13

[Matthew N. [:MattN]]

Comment on attachment 9105483 [details]
Bug 1591181 - Hide <login-item> whenever a login isn't selected even if there are search results. r=sfoster

(In reply to Pascal Chevrel:pascalc from comment #11)

Matt, do you think we can uplift it to beta or is it too risky and we should let it ship with 72? Thanks

Beta/Release Uplift Approval Request

• User impact if declined: From the most common entry point to about:logins (from autocomplete) where we pre-filter to the domain, if the user backspaces the domain to see other matches (e.g. remove the subdomain), they will see a "Create new Login" sidebar item and main view (showing 1970/1969 dates) when they shouldn't.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The CSS change seems like it now matches the intentions and the _blankLoginListItem change should be safe since its visibility should also be updated explicitly when it is shown so defaulting to hidden seems good.
• String changes made/needed: None

Comment 14

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9105483 [details]
Bug 1591181 - Hide <login-item> whenever a login isn't selected even if there are search results. r=sfoster

Fix for a P1 bug in about:logins, low risk patch, has tests and was verified on Nightly, uplift approved for 71 beta 8, thanks.

Comment 15

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/releases/mozilla-beta/rev/a4531f243d4e
https://hg.mozilla.org/releases/mozilla-beta/rev/ce7f134665e6

Comment 16

[Simona Rosu [:srosu], Ecosystem QA]

I have verified this issue on the Firefox Beta 71.0b8 (Build ID: 20191107101713) on Windows 10 x64, Mac 10.14, Ubuntu 16.04 x64.

• The “New Login” item is no longer displayed in the “Login List” after delete the prepopulated filter from the search bar that returns 0 results.