1575561 - The "Login Item" of a selected login is still displayed even if the search results don't include it or no logins are found

Status: NEW

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

Description

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Attachment: selected login when the search does not include it.gif

[Notes]:

• Based on the mock-ups the "Login Item" area should be blank if no results are found.

[Affected Versions]:

• Nightly 70.0a1

[Affected Platforms]

• All Windows
• All Mac
• All Linux

[Prerequisites]:

• Have a Firefox profile with multiple saved logins.

[Steps to reproduce]:

1. Open the latest Nightly browser with the profile from prerequisites.
2. Navigate to "about:logins" page.
3. Click on any saved login.
4. Perform a search that returns 0 results.
5. Observe the "Login Item" area.

[Expected results]:

• A blank area is displayed instead of the "Login Item" of the selected login.

[Actual results]:

• The "Login Item" is still displayed.

[Additional Notes]:

• Attached a screen recording of the issue.

Comment 1

[David Durst [:ddurst]]

Page 11 of the spec also shows that a message should be displayed in the login list in this situation.

Comment 2

[Matthew N. [:MattN]]

I'm not sure I agree with the expected result. This also seems like a low priority since I don't think there is much wrong with the current behaviour. The current behaviour has the advantage of not losing the state of what you're doing. Ryan, what do you think is the correct behaviour?

(In reply to David Durst [:ddurst] from comment #1)

Page 11 of the spec also shows that a message should be displayed in the login list in this situation.

That is filed as a separate bug.

Comment 3

[rgaddis]

My recommendation for how we handle this is a touch different than the expected results listed above:

If someone searches for a term that no longer matches the selected login, deselect that login and instead select the top item of the list that matches the search query. This could have the effect of cycling through multiple login detail views in quick succession (as someone is typing) but I think that's ok; we effectively allow someone easy access to the login they need without having to effectively click into a login from the list.

Comment 4

[rgaddis]

The current behaviour has the advantage of not losing the state of what you're doing.

That's fair... but if someone is searching, it may not matter that we dismiss the current details... this is a broader concern with the global approach, which suggests that an active item will always be present (the relationship between an item in the list, and its corresponding content) and currently this relationship breaks based on this use case.

If we maintain the current pattern, we'd want it to function as expected across all use cases.

Comment 5

[Matthew N. [:MattN]]

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

Comment 6

[katieC]

UX recommendation - please see original spec

As commented above:

[Expected results]: A blank area is displayed instead of the "Login Item" of the selected login.

This is expected result based on the user's action: searched for <n>, no matches for <n> found.

In regards to:

The current behaviour has the advantage of not losing the state of what you're doing.

The user has intentionally searched for something - this is exactly what they are doing. Showing mismatched result to a user search is very confusing and unexpected.

Additionally, as noted above, as the search results are filtered in the sidebar, highlight the top match as the user types.

If someone searches for a term that no longer matches the selected login, deselect that login and instead select the top item of the list that matches the search query. This could have the effect of cycling through multiple login detail views in quick succession (as someone is typing) but I think that's ok; we effectively allow someone easy access to the login they need without having to effectively click into a login from the list.

Comment 7

[ragimeg698]

The key to copy links is broken. It was broken in 88 and remains unfixed.

Copying links is a core function of a web browser. It is completely unreasonable that this function should be removed. Tens, maybe hundreds of millions of people use hotkeys. It is an absolutely normal, absolutely acceptable way to interface with a computer. All of those people have had to find solutions outside of Firefox, and for absolutely no reason.

A "replacement" key that is not physically usable is obviously not a replacement.

Since my legitimate reports about this critical bug are being removed, I'm leaving comments on other people's bugs.

---