Lighten LHN row hover colors

[shawnborton]

Explanation of Change

Facelift of the hover / selected / pressed background colors for the left-hand navigation rows and the horizontal tab component. Introduces two dedicated theme tokens — navItemHoverBG (product200) and navItemSelectedBG (product300) — and applies them only to navigation surfaces:

• Inbox LHN report rows
• Account settings LHN, Workspace editor LHN, Domain editor LHN (shared MenuItem, gated on role=tab)
• Spend (SearchTypeMenuItem + saved searches)
• Horizontal tabs (TabSelector, e.g. Workspaces page)
• Global left tab bar hover (Home / Inbox / Search / Workspaces / Account)

Behavior:

• Hover → product200, selected/active → product300 (previously product300 / product400).
• Pressed state now holds the hover/selected color and only dims via opacity (no distinct product500), matching Inbox across all these surfaces.
• Hover-ring border of the copiloted subscript avatar and the green/red status dots on the left tab bar updated to match the new product200 hover fill so the cutout stays seamless.
• Generic MenuItem usages (Home widgets, etc.), generic option rows, and selection lists are intentionally unchanged.
• High-contrast themes keep their prior stronger values (product300 hover / product400 selected) for legibility.

Fixed Issues

$ #98581
PROPOSAL:

Tests

1. Open NewDot web on the default theme.
2. Inbox LHN: hover a chat row → background is product200; the currently-open row → product300; press-and-hold a row → the color holds and the row only dims (no darker fill).
3. Global left tab bar: hover Home / Inbox / Search / Workspaces / Account → background is product200.
   • While copiloted into an account, hover the Account avatar → the subscript (delegate) avatar ring border matches the hover fill (no mismatched ring).
   • On an item showing a green/red status dot, hover it → the dot's border matches the hover fill.
4. Settings → Account, Workspace editor, Domain editor LHN rows: hover → product200, selected row → product300, press → color holds + opacity dim only.
5. Spend (search type menu and saved searches): same hover / selected / press behavior.
6. Workspaces page horizontal tabs: hovered tab → product200, active tab → product300.
7. Confirm Home widgets and other generic menu items are unchanged (hover product300 / selected product400 / pressed product500).
8. Switch to High Contrast (dark and light): the nav rows/tabs keep the stronger prior values — hover product300, selected product400.
9. Verify that no errors appear in the JS console.

Offline tests

No network-dependent behavior changed; hover/selected/pressed colors render identically offline.

QA Steps

Same as tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[shawnborton]

cc @dannymcclain @dubielzyk-expensify another one to take for a spin! This just lightens the LHN rows a bit like we talked about. I kept the scope quite small so we don't get too many weird edge cases with things like MenuItems inside of cardBGs. I also undid the pressed BG color that some of the LHN rows had (everything but Spend), which felt unnecessarily heavy. Now it just uses the app-wide default pressable dimming.

[dannymcclain]

Looks great!

Generic MenuItem usages (Home widgets, etc.), generic option rows, and selection lists are intentionally unchanged.

Do you think we'll plan on going through and updating these at some point as well? (Not a concern for this PR, I'm mostly just curious to hear your thinking about those)

[shawnborton]

I think that would be ideal, yup! I think it might get tricky to separate the logic for when a MenuItem is in a card or not, which dictates the rowHover color we need.

I guess thinking more on this - I almost wonder if we should try a rowHover color that just uses 50% opacity or something? This way we get the same hover effect but a lighter version no matter where we are...

[dannymcclain]

Ooo that's an interesting idea! Let's save that for when we tackle the menu items though. I think this can proceed as is and then if we do something like that when updating the menu items, we can just change it everywhere. (Unless you really want to mess with it here haha)

[shawnborton]

I will try it locally and report back! It might simplify things!

[shawnborton]

Tried it out but I think it makes the hover on top of cards a bit too subtle:

CleanShot.2026-08-13.at.11.23.12.mp4

Thoughts? Might not be easy to see in the video...

[shawnborton]

Though it would be a MUCH simpler implementation...

[dannymcclain]

I mean... I kinda think it's lovely 🤷 Can we run a build with it so I can test it out for realsies, or are you pretty convinced it's not a good idea?

Let's see what @dubielzyk-expensify thinks too!

[shawnborton]

Sure! Lemme push and build

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[dubielzyk-expensify]

No big opinion here. Agree with Shawn that its very subtle on highlightbg stuff but it's not terrible. I guess this is where that opacity for hover colors comes in clutch.

Happy to roll either way 👍

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[shawnborton]

Take it for a spin!

[dubielzyk-expensify]

I don't see heaps of difference in the latest one?

[shawnborton]

Hard refresh? I will run the build again though.

[github-actions]

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #98578.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-c863b52-85ce0b9-8ac1a7b8d808b30d82921ac74eada0e1f15f8942/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-c863b52-85ce0b9-8529b0c0bec28075fcc7fcf836de5efdd9acc8b3/index.html

Web 🕸️
https://98578.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[dubielzyk-expensify]

What should I look at? Haha. I dunno if I know what's changed in the last few

[shawnborton]

Basically all row hovers get this new alpha treatment. Whether that's a LHN row, a MenuItem, a table row, etc. The result: rows that use the lightest/darkest BG color (product100) have a more pronounced hover effect than say rows that use product200 (where they are baked within a card wrapper).

I don't necessarily mind it, as it's the cleanest way to solve this. It would make it so that we still only ever manage one row hover color in Figma and don't need to worry about managing multiple (depending on the surface color of what is being hovered...)

[dannymcclain]

LOL I'm having a hard time knowing if the build worked for sure - which I think is a good thing?? I think I like this though.

[shawnborton]

Another idea here might be to just use product300 (the same color as our current row-hover) for selected items in the LHN. Or a green shade for selected items like we discussed at one point?

Anyways I'm not entirely convinced we should do this one. I guess the main thing that bothers me is the selected item in the LHN feels heavier than it needs to be.