[C+ Checklist Needs Completion] [$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 [email protected] 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): [email protected]
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]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.57-10 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• change background color of focus element #51158
• change focus background color of element #51937

If no regressions arise, payment will be issued on 2024-11-13. 🎊

For reference, here are some details about the assignees on this issue:

• @jjcoffee requires payment automatic offer (Reviewer)
• @nkdengineer requires payment automatic offer (Contributor)

[melvin-bot]

@jjcoffee @greg-schroeder The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.59-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Handle disabled case when computing menu item background color #51988

If no regressions arise, payment will be issued on 2024-11-18. 🎊

For reference, here are some details about the assignees on this issue:

• @jjcoffee requires payment automatic offer (Reviewer)
• @nkdengineer requires payment automatic offer (Contributor)

[melvin-bot]

@jjcoffee @greg-schroeder The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[greg-schroeder]

Payment date is 11/18 to account for deploy blocker fixes

[greg-schroeder]

Timeline:

• Original PR (Author: @nkdengineer, Reviewer: @jjcoffee) deployed to staging 2024-10-31
• Reverted 2024-11-04 after several regressions arose
• New PR (Author: @nkdengineer, Reviewer: @jjcoffee) deployed to staging 2024-11-04, deployed to prod 2024-11-05
• Another regression occurred, prompting a new PR (Author: @luacmartins, Reviewer: @jjcoffee) deployed to prod 2024-11-11
• More regressions leading to this PR deployed 2024-11-11

So, it seems to me that this led to two distinct regression periods.

[greg-schroeder]

@mjasikowski @luacmartins Do you agree with the above that there were two regression periods here?

Original payment $250 -> $125 -> $62.50 per the payment guidelines (50% reduction per regression)

[greg-schroeder]

Payment summary:

Contributor: @nkdengineer - $62.50 - Upwork
C+: @jjcoffee - $62.50 - Upwork

[mjasikowski]

@greg-schroeder agreed on regressions

[greg-schroeder]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production
• 2b. Reported on staging (deploy blocker)
• 2c. Reported on both staging and production
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment:

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion:

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎

[greg-schroeder]

Thanks! All that's left is the checklist @jjcoffee

[jjcoffee]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production
• 2b. Reported on staging (deploy blocker)
• 2c. Reported on both staging and production
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: N/A this was never implemented in PopoverMenu

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion: N/A

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

• Have an account with a copilot.

Test:

1. Log in as a copilot.
2. Go to Account settings.
3. Click on the account switcher.
4. Navigate through the account list via keyboard arrows.
5. Verify that: The current account and the selected account are both highlighted but with different background colours.
6. Do the same with workspace switcher, emoji suggestion, emoji picker

Do we agree 👍 or 👎