feat(webapp): switch themes from the account menu

[samejr]

✅ Checklist

• I have followed every step in the contributing guide
• The PR title follows the convention.
• I ran and tested the code works

---

Testing

Ran the dashboard locally and switched between System, Light and Dark from the account menu — both in the expanded rail and in the collapsed rail, where the submenu nests inside Account — plus all four themes from the profile page, checking that data-theme followed each choice and persisted across reloads. Also dragged the contrast slider to confirm the percentage label tracks the handle and that the Appearance entry stays hidden for a non-admin while the hasThemeSwitcher flag is off.

---

Changelog

Adds an Appearance submenu to the account popover listing System, Light and Dark with a check against the current theme and a "More options" link to your profile, saved through a new /resources/preferences/theme endpoint behind the existing theme switcher flag. On Your profile the Theme and Contrast rows now match the layout of the Profile rows above them, and the contrast slider moves in steps of 1 with a percentage label above the handle.

---

Screenshots

To attach: the Appearance submenu open in the account popover, and the Appearance section on Your profile.

💯

---

Note for reviewers: storybook coverage after #4654

This branch merges main, which includes #4654 (enforce no unused deps or code in ci). That pass removed a set of primitives that had no importer anywhere — AnimatingArrow, PrettyDuration, SmartDateTime, LiveCountUp, InputOTPSeparator, PopoverSideMenuTrigger, TableCellChevron, LabelValueStack — plus a few exports it reduced to module-private.

That cleanup is kept exactly as written. Every file it touched is byte-identical to main on this branch. The consequence is that the storybook sections this branch had added for those components are removed too, so primitive coverage here is smaller than it was. Deliberate, not an oversight.

---

Open workspace in Conductor

[changeset-bot]

⚠️ No Changeset found

Latest commit: 61b390a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Observability map

As of 61b390a.

19/100 over 444 measured of 460 entry points (base 19, no change)

What this PR changed

route	base	head	now failing
/resources/preferences/theme	new	0	request-context

FIX FIRST

• /api/v1/projects/:projectRef/envvars (sensitive) - auth-boundary, request-context
• /auth/sso (sensitive) - auth-boundary, request-context
• /_app/orgs/:organizationSlug/settings/team (sensitive) - error-classification, auth-scope, request-context

AUDIT 3 of 50 sensitive mutations record an actor. 47 without one.
CONTEXT 22 of 444 entry points name a tenant on a failure path. 343 appear only here, 39 of them sensitive, in the JSON rather than the fix list.

What the score is made of

CHECKS
  error-classification  179 applicable, 102 pass,   0 sole, global without it 12
  auth-boundary          62 applicable,  57 pass,   0 sole, global without it 16
  auth-scope             19 applicable,  17 pass,   0 sole, global without it 19
  request-context       444 applicable,  22 pass, 243 sole, global without it 64
  audit-trail            50 applicable,   3 pass,   0 sole, not in the score

The score and findings here are report-only and never gate the merge. Separately, a required test suite keeps this tool's symbol and route lists in sync with the code they name, and can fail a pull request that renames or removes a symbol they reference, or that adds the first route with a segment they anticipate. Each failure names the list to edit. The rules and their reasons: internal-packages/observability-map/README.md.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

The PR adds reusable theme icons and shared theme option metadata. It adds a protected route that validates and saves theme preferences. The account menu now includes an appearance submenu with theme selection and an account link. The side-menu popover logic moves to a dedicated component. Account settings use centralized theme metadata and updated contrast controls. The slider supports marks and formatted value tooltips during hover and dragging.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 40.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the primary change: adding theme switching to the webapp account menu.
Description check	✅ Passed	The description includes the checklist, testing steps, changelog, and screenshots section, but it omits an issue reference and actual screenshots.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch samejr/appearance-theme-toggle

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[devin-ai-integration]

Devin Review found 4 potential issues.

[devin-ai-integration]

🟡 Trace log entries lose their colour and blend in with the rest of the list

The trace severity chip is painted with a colour name that doesn't exist in the design system (text-log-trace at apps/webapp/app/utils/logUtils.ts:108), so nothing is applied and the chip renders uncoloured.

Impact: On the Logs page, TRACE rows no longer stand out — the badge loses its purple text, tinted background and border, unlike every other severity.

Missing colour token behind the new chip styles

The rewrite of getLevelColor switched TRACE from raw palette utilities (text-purple-400 bg-purple-500/10 border-purple-500/20) to semantic ones (text-log-trace bg-log-trace/10 border-log-trace/20). Tailwind v4 generates these utilities from --color-* custom properties declared in @theme, but --color-log-trace is not declared anywhere — apps/webapp/app/tailwind.css has no such token, and a repo-wide search finds log-trace only at apps/webapp/app/utils/logUtils.ts:108. All three classes are therefore dropped at build time, leaving the chip with inherited text colour, a transparent background and Tailwind's default currentColor border.

The sibling changes in the same function are fine: --color-pending (used for INFO) is declared at apps/webapp/app/tailwind.css:186, and the DEBUG/default branches use black/5 and white/5, which need no token.

Prompt for agents

In apps/webapp/app/utils/logUtils.ts, getLevelColor now returns "text-log-trace bg-log-trace/10 border-log-trace/20" for the TRACE level, but no --color-log-trace custom property exists in apps/webapp/app/tailwind.css (or anywhere else), so Tailwind generates none of those three utilities and the chip renders with no colour at all. Either add a --color-log-trace token to the @theme block (and per-theme overrides alongside the other accents, so it follows the light themes and the Stronger colors preference the way the comment above the function claims), or fall back to an existing themable token. The other levels in the same function reference tokens that do exist (--color-error, --color-warning, --color-pending).

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 Customising the sidebar from the profile page can silently reset saved sidebar preferences

The sidebar customisation dialog on the profile page is built with no organisation feature flags available (useFeatureFlags() feeding buildSideMenuSections at apps/webapp/app/routes/account._index/route.tsx:774), so whole sidebar sections are missing from it and confirming wipes the choices previously saved for them.

Impact: A non-admin user who opens "Customize" from their profile sees a shorter list than their real sidebar, and pressing confirm makes items they had hidden reappear.

Feature flags come from the organization route, which is not mounted under /account

useFeatureFlags() (apps/webapp/app/hooks/useFeatureFlags.ts) reads useOptionalOrganization(), which looks up the route match routes/_app.orgs.$organizationSlug (apps/webapp/app/hooks/useOrganizations.ts:25-37). The account page renders under app/routes/account/route.tsx, not under the org layout, so that match never exists and the hook returns {}.

buildSideMenuSections gates two sections on those flags (apps/webapp/app/components/navigation/sideMenuSections.tsx:98 and :126): isAdmin || featureFlags.hasAiAccess for "AI" and isAdmin || featureFlags.hasQueryAccess for "Observability". For a non-admin whose org has those flags on, both sections are present in the real side menu (built inside the org route, where the flags resolve) but absent here.

The dialog's confirm handler rebuilds the whole preference payload from only the sections it was given (apps/webapp/app/components/navigation/CustomizeSidebarDialog.tsx:203-251): hiddenItems is recomputed by iterating sections, and sectionItemOrder likewise. Any hidden override or item order stored for ai / metrics items is therefore not re-emitted, and the save at apps/webapp/app/routes/account._index/route.tsx:815-818 replaces the stored preference — so those items silently become visible again and their ordering is lost.

The loader already resolves an organization for sidebarContext via SelectBestEnvironmentPresenter; the feature flags for that organization could be returned from the loader alongside it instead of being read from a client hook that has no org in scope.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔍 system: variant now keys off a preference rather than the theme — verify all existing call sites still read correctly

@custom-variant system changes from "the Dark or Light themes" to "data-icon-contrast="true" in any theme". Every pre-existing system:* utility in the codebase therefore flips meaning: styles that previously always applied on Dark/Light now only apply when the user opts into Stronger colors, and they additionally apply on Black/White when they do. The PR fixes the obvious casualties it found (Badge.tsx rounded, the run title in the span route), but this is a broad semantic change across every system: usage — worth a sweep of grep -r "system:" to confirm nothing else relied on the old "is a non-Classic theme" meaning (e.g. system-mono-label call sites, which now only go monochrome under the preference).

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔍 Default contrast dropped from 50 to 0 changes the look for everyone already on the theme switcher

DEFAULT_THEME_CONTRAST goes from 50 to 0 and normalizeThemePreference now maps the removed classic value onto dark. The comments argue Dark at contrast 0 reproduces the Classic palette exactly, which is plausible given the contrast blocks are color-mix(..., 0%) at contrast 0 — but the same change also drops anyone who was already on the new Dark/Light themes (and had no saved contrast) from a 50% contrast bump to 0%. That's a visible regression in perceived contrast for existing flagged users, and the changelog note doesn't mention it.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

🟡 Copy buttons no longer show their "Copy"/"Copied!" hover hint

The copy control is now handed straight to the hover-hint wrapper instead of being wrapped by it (asChild={variant === "button"} at apps/webapp/app/components/primitives/CopyButton.tsx:105), and the wrapper's hover handlers are silently dropped, so the hint never appears.
Impact: Hovering a copy button anywhere in the dashboard no longer shows the "Copy" tooltip, nor the "Copied!" confirmation after clicking.

Why the merged props are lost

With asChild, SimpleTooltip renders TooltipTrigger asChild (apps/webapp/app/components/primitives/Tooltip.tsx:93-100), which uses Radix Slot: it clones the child element with the trigger's props (onPointerEnter, onPointerLeave, onFocus, onBlur, data-state, aria-describedby).

The child here is the Button component, and Button does not spread unknown props onto its DOM node — it destructures a fixed allowlist (type, disabled, autoFocus, onClick, aria-label) and forwards the rest only into ButtonContent (apps/webapp/app/components/primitives/Buttons.tsx:392-429), which likewise renders plain divs and never spreads its props (apps/webapp/app/components/primitives/Buttons.tsx:250-265). So the pointer/focus handlers and the a11y attributes are discarded; only onClick survives (copying still works). Ref forwarding works, so positioning would be fine — the trigger simply never opens.

The icon variant keeps asChild={false} and is unaffected.

Prompt for agents

CopyButton now passes `asChild` to SimpleTooltip for the `button` variant to avoid nesting a <button> inside the tooltip trigger's own button. However Radix's Slot forwards the trigger's props (onPointerEnter/onPointerLeave/onFocus/onBlur, data-state, aria-describedby) to the child component, and `Button` in apps/webapp/app/components/primitives/Buttons.tsx does not spread unknown props onto its underlying <button> — it forwards only a fixed allowlist and passes the rest to ButtonContent, which also drops them. The result is that the hover tooltip never opens for the button variant. Options: make `Button` spread remaining DOM-safe props onto its <button> element, or wrap the Button in a plain <span> passed as the tooltip trigger child (with asChild) so the handlers land on a real DOM node, or use the Button component's own built-in `tooltip` prop instead of SimpleTooltip here.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔍 Existing theme preference test still asserts the removed "classic" value

apps/webapp/test/themePreference.test.ts declares const VALID_THEMES: ThemePreference[] = ["classic", "system", "dark", "light"] and asserts normalizeThemePreference(theme) returns each value unchanged, plus that parseDashboardPreferences accepts each. With classic removed from the enum in apps/webapp/app/utils/themePreference.ts:5, the test no longer typechecks and both assertions fail at runtime ("classic" now normalizes to "dark"). The test also never covers the two new values (black, white) or the new SystemLightTheme/SystemDarkTheme normalizers. Worth updating in this PR so CI stays green.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[trigger-dot-bot]

Preview Deployment

Status	Preview	Commit	Updated
🟢 Ready	samejr-appearance-theme-toggle.triggerlabs.dev	61b390a	Aug 19, 12:06 UTC

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

🔴 Logs navigation disappears for teams that only have logs access

The Observability group of the sidebar is now only built for people with query access (isAdmin || featureFlags.hasQueryAccess at apps/webapp/app/components/navigation/sideMenuSections.tsx:126), instead of also for people who only have logs access, so those users lose the Logs entry from the sidebar entirely.

Impact: Organisations enabled for the Logs page but not Query can no longer reach Logs from the sidebar.

How the section gate changed when the config moved out of SideMenu.tsx

The original code in SideMenu.tsx gated the section with isAdmin || featureFlags.hasQueryAccess || featureFlags.hasLogsPageAccess, and then gated the Errors/Query/Queues/Dashboards items with an inner isAdmin || featureFlags.hasQueryAccess spread. The extracted version keeps the inner Logs check (apps/webapp/app/components/navigation/sideMenuSections.tsx:131) but narrows the outer gate to isAdmin || featureFlags.hasQueryAccess and makes Errors/Query/Queues/Dashboards unconditional. Net effect: with hasLogsPageAccess: true, hasQueryAccess: false (independent flags, see apps/webapp/app/v3/featureFlags.ts), the whole section — including Logs — is now dropped. The Logs route itself still authorizes such users (apps/webapp/app/routes/_app.orgs.$organizationSlug.projects.$projectParam.env.$envParam.logs/route.tsx:76), so the page exists but is unreachable from the menu.

Prompt for agents

When the side-menu section config was extracted from SideMenu.tsx into buildSideMenuSections, the Observability section's gate lost the hasLogsPageAccess branch: it is now `isAdmin || featureFlags.hasQueryAccess`, where the original was `isAdmin || featureFlags.hasQueryAccess || featureFlags.hasLogsPageAccess`. At the same time the Errors/Query/Queues/Dashboards items, which the original only included under `isAdmin || featureFlags.hasQueryAccess`, are now unconditional inside the section. Restore the original semantics: the section should appear when the user is an admin or has either flag, the Logs item should be gated on `isAdmin || hasLogsPageAccess`, and the query-only items should be gated on `isAdmin || hasQueryAccess`. hasLogsPageAccess and hasQueryAccess are independent org feature flags.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

🔍 Email change no longer confirms basic details

The single-form action previously called updateUser, which (per the new comment in apps/webapp/app/models/user.server.ts:401-406) also confirmed basic details as a side effect. The per-field writes deliberately drop that. If any onboarding gate keys off confirmedBasicDetails, a user who only ever edits their name/email from this page will no longer clear it — previously editing the profile did. Worth checking whether onboarding relies on the profile page as a path to confirmation.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔍 Nested-button hydration fix is scoped to one variant only

asChild/tabbable are keyed off variant === "button", which fixes the nested-<button> hydration failure for that variant. The icon variant renders through a different path — worth confirming it isn't also a real <button> under the tooltip trigger, since the same parser/hydration problem would apply there and the conditional would silently leave it broken.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 1 new potential issue.

[devin-ai-integration]

🔍 Stored classic preference silently maps to Dark at contrast 0, but saved contrast is preserved

normalizeThemePreference now rejects classic and falls back to dark, and DEFAULT_THEME_CONTRAST drops from 50 to 0 so the fallback reproduces Classic's palette. Note this only holds for users with no saved contrast value: a user who previously picked Classic and moved the contrast slider keeps their stored contrast, which is now applied to Dark (Classic never read --theme-contrast). Those users will see a contrast shift on first load after deploy. Probably acceptable, but worth a conscious decision since there's no migration of the stored preference.

---

Was this helpful? React with 👍 or 👎 to provide feedback.