Lighten LHN row hover colors

[shawnborton]

Explanation of Change

Facelift of the hover / selected / pressed states for rows across the app, driven off the product color scale:

Selected / active → product300 (was product400)

• activeComponentBG is now product300 (dark + light). Contrast themes inherit it.
• The menu-item ACTIVE background (getButtonBackgroundColorStyle) and the horizontal tab active background (TabSelector/getBackground) now resolve to activeComponentBG instead of theme.border, so Inbox LHN, Account/Workspace/Domain settings rows, Spend, tabs, and selection-list rows all use product300 when selected.

Pressed → no distinct color, opacity dim only (matching the Inbox LHN rows)

• MenuItem and SearchTypeMenuItem no longer flash a pressed background (previously product500). A press keeps the resting background (selected / hover / default) and provides feedback purely by dimming opacity, the same way Inbox rows already behaved.

Hover = the row's own background, one product step darker

• New StyleUtils.getRowHoverBackgroundColor / getRowHoverBackgroundColorStyle map a background to the next product step (product100→200, 200→300, 300→400).
• A row's surface background is provided via a new SurfaceBackgroundColorContext. Section and WidgetContainer (the dominant card wrappers) provide cardBG (product200), so their MenuItems hover to product300. Rows on appBG/sidebar (product100) — Inbox LHN, settings nav lists, Spend — hover to product200.
• Both the legacy MenuItem and the compound MenuItemRoot read the context. MenuItem also accepts an explicit backgroundColor prop that takes precedence for one-off surfaces.

Net result: a hovered row is always exactly one product step darker than the surface it sits on (so it reads correctly on appBG and on cards), the selected state is product300, and a press just dims.

Fixed Issues

$ #98581
PROPOSAL:

Tests

1. Open NewDot web on the default (non–high-contrast) theme.
2. Inbox LHN (rows sit on product100): hover a chat row → background is product200; the open/selected row → product300; press-and-hold a row → the color holds and the row only dims.
3. Account settings / Workspace editor / Domain editor nav lists (on appBG/product100): hover → product200, selected → product300, press → holds + dims.
4. Cards — Workspace/Account/Domain settings cards (Section) and Home widgets (WidgetContainer), whose rows sit on cardBG/product200: hover a card row → product300 (a visible hover, not matching the card), press → holds + dims.
5. Spend (search type menu) and horizontal tabs (Workspaces page): hover → product200, selected/active → product300.
6. Confirm the hover on any row is exactly one product step darker than its surface, and never invisible.
7. 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.

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

[dannymcclain]

Totally down to keep tinkering! This isn't super urgent or anything. Probably better to get it right the first time so we're not changing these hovers/actives a bunch.

[dubielzyk-expensify]

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.

Agree with that. Could we do row-hover on selected elements and row-hover opacity 50% on hover? Or would that be silly silly?

[shawnborton]

I think that's what we currently have in this PR.

But the more I think about it, our current rowHover color is kinda nice because it doesn't cause any collisions anywhere with buttons/badge colors/etc. So maybe the right call here is to leave the rowHover color untouched, and just reduce the selectedRow color to use something lighter - perhaps even the same rowHover color.

But that being said... I think I lean towards doing nothing for now, let's get back to this one later on as I don't think it's pressing.

[dubielzyk-expensify]

I'm okay with doing nothing since it's not the biggest priority, but I think we'll have to have the same discussion at some point either way.

I don't mind your idea. Maybe if we can do a quick melvin explorations with just using row-hover for all. I have a feeling we won't love it given it'll be indistinguishable in the nav LHNs.

But again, totally fine if we just wanna close and do later

[codecov]

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/components/MenuItem/MenuItem.tsx	92.96% <100.00%> (ø)
src/styles/theme/themes/dark.ts	100.00% <ø> (ø)
src/styles/theme/themes/light.ts	100.00% <ø> (ø)
src/styles/utils/index.ts	57.00% <100.00%> (-0.24%)	⬇️
src/components/TabSelector/getBackground.ts	55.55% <33.33%> (ø)
src/pages/Search/SearchTypeMenuItem.tsx	6.25% <0.00%> (-0.21%)	⬇️
... and 299 files with indirect coverage changes

[github-actions]

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

[shawnborton]

Okay I tried making the selected item the same color as rowHover and it felt terrible, so back to the drawing board.

Going to try another approach here (see PR description) that basically gives us the first idea we had - only go 1 step darker from the current surface color when hovering. That technically gives us two different row hover colors but it sure feels nice? Let's see the builds when they arrive!

[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-6714c62-5704fd4-242e4555bcbda856bedbba5584a3ca75b4bfe76f/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-6714c62-5704fd4-8f0aacdca9d7d63b7b9df4129471a0328ffb1c4f/index.html

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

---

👀 View the workflow run that generated this build 👀

[dubielzyk-expensify]

I actually quite like this 👍 Select color is still more subtle and the hover feels distinct enough. Also looks good on a highlight bg. What do you think? I'm into it!