[$250] Copilot - Two accounts are highlighted in account list when navigating via keyboard

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.0.49-0
Reproducible in staging?: Y
Reproducible in production?: N
Email or phone of affected tester (no customers): applausetester+kh081006@applause.expensifail.com
Issue reported by: Applause Interna Team

Action Performed:

1. Go to staging.new.expensify.com
2. Log in as a copilot.
3. Go to Account settings.
4. Click on the account switcher.
5. Navigate through the account list via keyboard.

Expected Result:

The current account will no longer be highlighted and the selected account will be highlighted (same behavior as workspace switcher).

Actual Result:

Both the current account and the selected account are highlighted when navigating via keyboard.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6634911_1728972462581.20241015_140418.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021846231572731332050
• Upwork Job ID: 1846231572731332050
• Last Price Increase: 2024-10-15
• Automatic offers:
• jjcoffee | Reviewer | 104458668
• nkdengineer | Contributor | 104458669

Issue Owner

Current Issue Owner: @jjcoffee

[melvin-bot]

Triggered auto assignment to @mjasikowski (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

Triggered auto assignment to @greg-schroeder (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[mjasikowski]

Account switcher component was changed in this PR: #49051 - this is most likely the offender

[nkdengineer]

@mjasikowski In this PR, we discussed this and agreed it isn't a problem.

[mjasikowski]

@Expensify/design can you weigh in here and let us know if this is OK or expected? I personally have seen this behavior outside of NewApp and I'm used to it in terms of UX, so it doesn't bother me - but nevertheless we need to either change this or readjust QA to take the new keyboard navigation into account when doing tests.

[nkdengineer]

Currently, this is the behavior of other PopoverMenu components.

Screen.Recording.2024-10-15.at.15.46.30.mov

[shawnborton]

Interesting, I think I would expect the keyboard navigation to use the same background color as hover. So this way we save the selected color for when a row is truly selected/checked, and we just reuse a background hover highlight for keyboard nav. Thoughts on something like that?

[s77rt]

We were aware of this during PR review and the bug is not new, it's an existing bug in PopoverMenu which we switched to. This should be fixed to match the behaviour on the SelectionList. This does not need to be a deploy blocker though

Screen.Recording.2024-10-15.at.10.41.12.AM.mov

Screen.Recording.2024-10-15.at.10.42.02.AM.mov

[mjasikowski]

OK, removing the deployblocker tag for now and switching this to weekly

[dannymcclain]

I think I would expect the keyboard navigation to use the same background color as hover. So this way we save the selected color for when a row is truly selected/checked, and we just reuse a background hover highlight for keyboard nav.

Agree with this. I feel like this is the most common pattern I see for this type of thing.

[s77rt]

Does that mean we'd have to change the behaviour on other lists i.e. the ones that use SelelctionList. On such lists the keyboard navigation clears the background from the checked item and moves it to the selected one. Check the example above on language selector page.

[dannymcclain]

Personally I think we should. IMO selected items should always have a background and the hover color makes more sense for keyboard navigating. Just because something is focused with the keyboard doesn't mean it's selected, so I think keyboard navigating is more similar to hovering with a mouse cursor than it is having the item selected. :my_two_cents:

[shawnborton]

Yup, I agree with Danny here

[s77rt]

Got it 👍

[s77rt]

@greg-schroeder Let's make this External

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @jjcoffee (External)

[s77rt]

@jjcoffee I can take this over as C+ if you want

[nkdengineer]

Edited by proposal-police: This proposal was edited at 2024-10-15 19:22:02 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Both the current account and the selected account are highlighted when navigating via keyboard.

What is the root cause of that problem?

When an item is focused, the background color is calculated by getButtonBackgroundColorStyle function here

App/src/components/MenuItem.tsx

Lines 586 to 588 in 4f1224c

	StyleUtils.getButtonBackgroundColorStyle(getButtonState(focused || isHovered, pressed, success, disabled, interactive), true),
	...(Array.isArray(wrapperStyle) ? wrapperStyle : [wrapperStyle]),
	shouldGreyOutWhenDisabled && disabled && styles.buttonOpacityDisabled,

In PopoverMenu we passed the background color as the focused background color above

App/src/components/PopoverMenu.tsx

Line 322 in 4f1224c

style={{backgroundColor: item.isSelected ? theme.activeComponentBG : undefined}}

So the selected item and the focused item by keyboard has the same background color

What changes do you think we should make in order to solve the problem?

We can pass wrapperStyle with backgroundColor color as a hover background color if the keyboard focuses on an item and it's not a selected item to override the default focused background color. We can do something like this and remove the style prop here

wrapperStyle={{backgroundColor: item.isSelected ? theme.activeComponentBG : focusedIndex === menuIndex ? theme.hoverComponentBG : undefined}}

App/src/components/PopoverMenu.tsx

Line 322 in 4f1224c

style={{backgroundColor: item.isSelected ? theme.activeComponentBG : undefined}}

Or if we don't want to remove style prop we can do something like this

wrapperStyle={{backgroundColor: !item.isSelected && focusedIndex === menuIndex ? theme.hoverComponentBG : undefined}}

We should check for all the places we're using useArrowKeyFocusManager and do the same solution to fix this bug.

• For SelectionList we can fix in BaseListItem by adding background style as hover bg color to wrapperStyle in this case isFocused is true and item.isSelected is false. We can discuss more if it has some edge case in the PR

App/src/components/SelectionList/BaseListItem.tsx

Line 103 in e8a8c53

wrapperStyle={pressableWrapperStyle}

• For AutocompleteSuggestion: We can return the same color in the case the currentEmojiIndex is equal to the highlightedEmojiIndex and the case this component is hovered. For this component, it doesn't have the selected case

• For other places that I checked, we're using MenuItem component then we can do the same fix that we do for PopoverMenu above

App/src/styles/utils/index.ts

Line 1214 in e8a8c53

if (currentEmojiIndex === highlightedEmojiIndex) {

What alternative solutions did you explore? (Optional)

NA

Result

Screen.Recording.2024-10-16.at.01.15.12.mov

[nkdengineer]

@shawnborton Is the resulting video in my proposal the expected behavior we want?

[s77rt]

@nkdengineer Let's fix the inconsistency with the other lists too e.g. SelectionList

[nkdengineer]

Updated proposal to include the other places.

[dannymcclain]

@shawnborton Is the resulting video in my proposal the expected behavior we want?

That looks correct to me.

[shawnborton]

Yup agree with Danny, that looks like what I had in mind.

[jjcoffee]

@nkdengineer's proposal LGTM! I'm a little unsure about blanket-changing this in other areas (the PopoverMenu seems much more clearly an issue).

For AutocompleteSuggestion, for example, it feels natural that you can navigate with the keyboard arrows to change the "selected" suggestion whilst we still have the hover effect for the mouse interaction. I don't think this should change.

auto-suggest-2024-10-16_11.43.37.mp4

I'm unsure about changing how this works in search too, as this feels pretty natural that there's a distinct hover effect from the mouse, and then the keyboard navigation is changing the "selected" item (i.e. that will be chosen on pressing enter).

search-highlights-2024-10-16_11.44.14.mp4

I wonder if we should focus on fixing the most obvious problem with PopoverMenu first so we don't change too much at once?

🎀👀🎀 C+ reviewed

[melvin-bot]

Current assignee @mjasikowski is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[jjcoffee]

@s77rt Sorry I have literally zero work at the moment, so I can't really pass on this one 😅

[dannymcclain]

@jjcoffee I'd like for @Expensify/design to weigh in, but I don't really see a difference between hovering with your cursor and navigating through the choices with your keyboard. In the examples you showed, nothing has actually been selected yet, so it still makes sense to me to use the hover background color. I think as long as there is a clear indicator that you have something "focused" while navigating/hovering, it's fine. But maybe I'm alone in this feeling!

[shawnborton]

I don't have anything else to add, I agree with Danny - again that was my original feedback about this and I think we should have used this style for this interaction all along.

[greg-schroeder]

Does anyone have thoughts on which project board this live under?

[dubielzyk-expensify]

I don't really see a difference between hovering with your cursor and navigating through the choices with your keyboard

Agree. Same intent, different input device.

[jjcoffee]

Great, thanks for confirming the expected behaviour all. Just waiting for @mjasikowski to assign @nkdengineer then!

[melvin-bot]

📣 @jjcoffee 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @nkdengineer 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[greg-schroeder]

PR review continues