Open Bug 1575561 Opened 2 years ago Updated 1 year ago

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

Categories

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

Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- disabled
firefox70 --- wontfix

People

(Reporter: cmuntean, Unassigned)

References

()

Details

Attachments

(1 file)

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

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

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.

Flags: needinfo?(rgaddis)
Priority: -- → P3

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.

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.

Flags: needinfo?(rgaddis)
Component: Password Manager → about:logins
Product: Toolkit → Firefox
Version: 70 Branch → unspecified

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

Whiteboard: [passwords:management] [skyline]

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.

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