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

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

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.

(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.

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

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

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

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

I confirmed that the test fails without the fix.

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

Depends on D51234

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

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

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 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 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.

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

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.