1576026 - Selecting a login from login-list immediately puts focus on the Edit button in the login-item

Status: NEW

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

Description

[David Durst [:ddurst]]

Focus should remain on the selected login in the list until some other action (click or tab), which would then put focus on the Edit button in login-item.

Comment 1

[David Durst [:ddurst]]

This is actually a little more significant than just Edit getting focus. You can't see anything in the login-item without selecting it from the list -- but when the list has focus, it's not entirely clear visually.

The question is whether someone is selecting the list item to see it or to interact with it in more detail. That tabbing back to the list isn't readily apparent makes this, to me, worse.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

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

This is actually a little more significant than just Edit getting focus. You can't see anything in the login-item without selecting it from the list -- but when the list has focus, it's not entirely clear visually.

The question is whether someone is selecting the list item to see it or to interact with it in more detail. That tabbing back to the list isn't readily apparent makes this, to me, worse.

We are focusing the Edit button per the feedback in https://bugzilla.mozilla.org/show_bug.cgi?id=1560359#c0. We focused the Edit button instead of the Title since the title is non-interactive and focusing non-interactive elements isn't normal (https://phabricator.services.mozilla.com/D35828#1085745).

Comment 3

[David Durst [:ddurst]]

This is hard to argue with.

I think we have to punt on this for now and see if there are issues with it. Not normal could end up being more useful, but I'm curious if there will be a11y reports about it.

Comment 4

[Matthew N. [:MattN]]

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

Comment 5

[katieC]

UX recommendation (+based on conversation with accessibility team member) confirms original bug and expected results.
When selecting a login from this list with a keyboard or mouse we should not shift keyboard focus. Keep focus on the login in list itself.

Comment 6

[Matthew N. [:MattN]]

(In reply to katieC from comment #5)

UX recommendation (+based on conversation with accessibility team member) confirms original bug and expected results.
When selecting a login from this list with a keyboard or mouse we should not shift keyboard focus. Keep focus on the login in list itself.

Jamie, I think this contradicts what you told Jared in Whistler… what do you think about this?

Comment 7

[James Teh [:Jamie]]

When you're using the arrow keys to choose a login, obviously we shouldn't move focus (and we don't). When you press enter, I still think it makes sense to focus something within the details area (as we do now), since otherwise, a screen reader user has no idea that anything actually happened. A user's attention should be drawn to the area of interest (the login details), since that's what they're interested in.

Comment 8

[David Durst [:ddurst]]

The conversation in the original patch (https://phabricator.services.mozilla.com/D35828#1085745) recommended putting the focus on something other than the Edit button, but Jaws' response indicates that this might not be possible. So we're left with one of two things:

1. focus on the the first focusable element, as it is now (the Edit button)
2. don't place focus in the <login-item>

The ideal resolution here to accommodate a11y is what's described in the original patch review. So unless someone knows how to resolve the issue described at https://phabricator.services.mozilla.com/D35828#1089220, this will be resolved WONTFIX.

Comment 9

[Marco Zehe (:MarcoZ)]

OK, so what's the actual problem now? If focusing the edit button, after pressing Enter or clicking an item to select it, visually this should be clear that the focus is now in the login item that just appeared. From a screen reader perspective, the only thing above the login item (prior DOM element) is the heading that repeats the title of the login item I just selected. Everything else follows the Edit button in the DOM order, like the URL, user name and concealed password plus checkbox to reveal it. A keyboard user would also be focused on the Edit button for the login item. And the fields below are read-only, but focusable, which means they can be tabbed to and the text selected and copied.

I fail to see what the actual problem is with the current implementation.

Comment 10

[Matthew N. [:MattN]]

(In reply to Marco Zehe (:MarcoZ) from comment #9)

OK, so what's the actual problem now? If focusing the edit button, after pressing Enter or clicking an item to select it, visually this should be clear that the focus is now in the login item that just appeared.

I believe UX doesn't like seeing the visual focus outline on the edit button when a mouse user clicks an item to select it. I'm not sure if that is the extent of the problem though.

Comment 11

[Markus Keller]

Bug 1579739 (missing multi-selection/-deletion) is an example why focusing another element on click is a bad idea.

There are well-established patterns for user interaction with lists.
One is quick browsing via the keyboard. This is very cumbersome right now.
Scenario:

1. type "faceb" in the search field
2. press Enter key -> focus stays in search field
3. press Tab four times -> finally, the list gets keyboard focus, although that very hard to see
4. press Down Arrow -> next list item gets selected, but information on the right does not get updated
5. press Space or Enter -> finally, the info area gets updated, but focus gets stolen (this bug)
6. press Shift+Tab twice to get back to the list

Expected:
@2. focus should go to list
@3. <eliminated>
@4. right pane should always show the list item that has keyboard focus (mostly eliminates need for 5. and 6.)
@5. it's acceptable that Space and Enter put focus on the edit button. However, putting focus on the "Show Password" button would probably better cover the 90% use case

Comment 12

[James Teh [:Jamie]]

Comment 11 sounds like a good UX to me, both from a keyboard perspective and a screen reader perspective. However, I don't think it solves bug 1579739 from a mouse perspective.

One possibility is that enter focuses something inside the login area, but clicking does not. That does make the UX different for mouse and keyboard users, but the focus shift is more important for keyboard users anyway; mouse users are going to end up having to click to activate regardless.

Comment 13

[Marco Zehe (:MarcoZ)]

Agree with Jamie on all counts, including the distinction whether something got selected with the mouse rather than the keyboard. Besides, the UX will be similar in that selecting will already bring up the login details, only the extra pressof Space/Enter on the list item will shift focus. So that's an action a mouse user won't perform normally anyway. These sound like actionable items to me. :)

Comment 14

[Markus Keller]

The behavior should not differ between mouse clicks and selection via keyboard:

• For users who exclusively use the mouse, putting the focus on an other button is irrelevant.
• For users who use all available input methods, putting the focus on an other element on click violates basic UX expectations.

Whenever you start thinking about inventing new UI metaphors, take a step back and check if the problem at hand is really a completely new situation that needs a design from scratch. A list of entries + a details view for a selected entry is definitely not something new.

BTW: An even simpler solution would be a table with direct edit functionality ... didn't I see that somewhere, recently? 😏

Comment 15

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

---

Comment 16

[marcus]

The behavior you described, where selecting a login from a login-list immediately puts the focus on the "Edit" button in the login-item, is a common user interface pattern in many applications, especially those related to password managers or login management tools. This behavior is designed to streamline the process of editing or updating login credentials. Here's how it typically works:

Login List: The application displays a list of saved logins, each represented as an item in the list. These items usually show the name or description of the login along with the username or website associated with it.

Selecting a Login: When the user clicks or selects a specific login item from the list, the application assumes that the user wants to perform an action related to that login.

Immediate Focus on Edit: To make it convenient for users to update or edit their login information (such as changing the password), the application automatically sets the focus on the "Edit" button or a similar action button within the selected login item.

Edit Action: Once the focus is on the "Edit" button, the user can press the Enter key or click the "Edit" button to access the edit screen or dialog for that particular login. This allows them to make changes, update the password, or modify other login details.

This design pattern helps users quickly access and update their login information without the need for additional clicks or navigation steps. It's especially useful in situations where users frequently need to change passwords or manage their login credentials.

Please note that the specific implementation and user interface may vary depending on the application or platform you're using. However, the general concept of immediately focusing on the "Edit" button when selecting a login from a list is a user-friendly approach that enhances the user experience.
Regards: https://crackstab.com/