From 1fa994e09fe2255ca9c893bf97849541c6a6bb50 Mon Sep 17 00:00:00 2001
From: Sophie Neumann <sneumann@byte5.de>
Date: Fri, 26 Jun 2026 14:53:07 +0200
Subject: [PATCH 1/2] fix(ui): update dropdown font + bg color

---
 web-ui/app/_components/LocaleSwitcher.tsx     |  2 +-
 web-ui/app/_components/ThemeControls.tsx      | 12 ++-----
 .../__tests__/ThemeControls.test.tsx          | 32 +++++++++++++++++++
 web-ui/app/globals.css                        | 31 ++++++++++++++++++
 4 files changed, 66 insertions(+), 11 deletions(-)
 create mode 100644 web-ui/app/_components/__tests__/ThemeControls.test.tsx

diff --git a/web-ui/app/_components/LocaleSwitcher.tsx b/web-ui/app/_components/LocaleSwitcher.tsx
index a4f0468c..192836f5 100644
--- a/web-ui/app/_components/LocaleSwitcher.tsx
+++ b/web-ui/app/_components/LocaleSwitcher.tsx
@@ -34,7 +34,7 @@ export function LocaleSwitcher(): React.ReactElement {
         className="appearance-none rounded-md border border-[color:var(--border)] bg-transparent px-2 py-1 text-xs uppercase tracking-[0.18em] text-[color:var(--muted-ink)] outline-none transition-colors hover:text-[color:var(--ink)] focus:border-[color:var(--accent)] disabled:opacity-50"
       >
         {LOCALES.map((locale) => (
-          <option key={locale} value={locale} className="bg-[color:var(--bg)] text-[color:var(--ink)]">
+          <option key={locale} value={locale}>
             {locale.toUpperCase()} · {LOCALE_LABELS[locale]}
           </option>
         ))}
diff --git a/web-ui/app/_components/ThemeControls.tsx b/web-ui/app/_components/ThemeControls.tsx
index dd615fd1..9b7cce18 100644
--- a/web-ui/app/_components/ThemeControls.tsx
+++ b/web-ui/app/_components/ThemeControls.tsx
@@ -105,11 +105,7 @@ export function ThemeControls(): React.ReactElement {
           className={selectClass}
         >
           {PALETTES.map((p) => (
-            <option
-              key={p}
-              value={p}
-              className="bg-[color:var(--bg-elevated)] text-[color:var(--fg)]"
-            >
+            <option key={p} value={p}>
               {t(`palette.${p}`)}
             </option>
           ))}
@@ -134,11 +130,7 @@ export function ThemeControls(): React.ReactElement {
           className={selectClass}
         >
           {THEMES.map((m) => (
-            <option
-              key={m}
-              value={m}
-              className="bg-[color:var(--bg-elevated)] text-[color:var(--fg)]"
-            >
+            <option key={m} value={m}>
               {t(`appearance.${m}`)}
             </option>
           ))}
diff --git a/web-ui/app/_components/__tests__/ThemeControls.test.tsx b/web-ui/app/_components/__tests__/ThemeControls.test.tsx
new file mode 100644
index 00000000..f052d8b9
--- /dev/null
+++ b/web-ui/app/_components/__tests__/ThemeControls.test.tsx
@@ -0,0 +1,32 @@
+import { describe, expect, it } from 'vitest';
+
+import { renderWithIntl } from '../../_lib/test-utils';
+import { ThemeControls } from '../ThemeControls';
+
+/**
+ * Regression guard for issue #360 — the previous `<option>` markup carried
+ * `className="bg-[color:var(...)] text-[color:var(...)]"` props, which the
+ * Windows native combobox widget silently ignores (CSS custom properties do
+ * not reach option painting). Option colors now live in `[data-theme]`-
+ * scoped rules in globals.css with concrete hex values; the per-option
+ * className must not come back, or contributors would assume it does
+ * something.
+ */
+describe('<ThemeControls />', () => {
+  it('renders both selects with the expected options and no inline color classes', () => {
+    const { container } = renderWithIntl(<ThemeControls />);
+
+    const selects = container.querySelectorAll('select');
+    expect(selects).toHaveLength(2);
+
+    const options = container.querySelectorAll('option');
+    expect(options).toHaveLength(6);
+
+    const values = Array.from(options).map((o) => o.getAttribute('value'));
+    expect(values).toEqual(['lagoon', 'petrol', 'atelier', 'system', 'light', 'dark']);
+
+    for (const option of options) {
+      expect(option.getAttribute('class')).toBeNull();
+    }
+  });
+});
diff --git a/web-ui/app/globals.css b/web-ui/app/globals.css
index 3c386df9..dad3b5b0 100644
--- a/web-ui/app/globals.css
+++ b/web-ui/app/globals.css
@@ -651,6 +651,37 @@ textarea:focus {
     0 0 0 4px var(--accent-glow),
     0 0 12px var(--accent-glow-core);
 }
+
+/* Native <select> popup options (issue #360). Windows Chromium/Edge renders
+   the option list through the OS combobox widget. Two relevant quirks:
+     1. The widget ignores CSS custom properties (`var(--…)`) on <option>,
+        so token references would not paint.
+     2. The widget does NOT inherit the page's `color-scheme` into its
+        popup surface — in a dark-themed page the popup still draws on the
+        OS light background. That breaks any `light-dark()` value at the
+        <option> level: it resolves against the page's color-scheme (dark)
+        and yields a near-white text color that lands on the OS-light
+        popup background — unreadable.
+   Solution: pick the option color pair directly off the page's
+   [data-theme] attribute on <html>, so background and foreground always
+   carry a matching contrast pair regardless of whether the OS popup ends
+   up honoring the background-color or only the color. Concrete hex values
+   mirror --bg-surface-raised-top / --text-primary in theme.css; keep in
+   sync if those tokens change. */
+:root[data-theme='dark'] select option {
+  background-color: #303440;
+  color: #EEEFF3;
+}
+:root:not([data-theme='dark']) select option {
+  background-color: #FFFFFF;
+  color: #1B1D24;
+}
+@media (prefers-color-scheme: dark) {
+  :root:not([data-theme]) select option {
+    background-color: #303440;
+    color: #EEEFF3;
+  }
+}
 /* Checked choice controls emit a small glow (§4.2 choice/toggle). */
 input[type='checkbox']:checked,
 input[type='radio']:checked {

From 6f3a1cac0d0b34377e534313d82c3e44f30c0c29 Mon Sep 17 00:00:00 2001
From: Sophie Neumann <sneumann@byte5.de>
Date: Mon, 29 Jun 2026 10:53:12 +0200
Subject: [PATCH 2/2] fix: implement pr feedback

---
 .../__tests__/LocaleSwitcher.test.tsx         | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 web-ui/app/_components/__tests__/LocaleSwitcher.test.tsx

diff --git a/web-ui/app/_components/__tests__/LocaleSwitcher.test.tsx b/web-ui/app/_components/__tests__/LocaleSwitcher.test.tsx
new file mode 100644
index 00000000..76ef92c7
--- /dev/null
+++ b/web-ui/app/_components/__tests__/LocaleSwitcher.test.tsx
@@ -0,0 +1,37 @@
+import { describe, expect, it, vi } from 'vitest';
+
+import { LOCALES } from '../../../i18n/locales';
+import { renderWithIntl } from '../../_lib/test-utils';
+import { LocaleSwitcher } from '../LocaleSwitcher';
+
+vi.mock('next/navigation', () => ({
+  useRouter: () => ({ refresh: vi.fn() }),
+}));
+
+/**
+ * Regression guard for issue #360 — same rationale as ThemeControls.test.tsx:
+ * the Windows native combobox widget silently ignores per-`<option>` styling
+ * driven by CSS custom properties, so any `bg-[color:var(...)]` /
+ * `text-[color:var(...)]` className on `<option>` is a no-op there. Option
+ * colors are owned by `[data-theme]`-scoped rules in globals.css with
+ * concrete hex values; the per-option className must not come back, or
+ * contributors would assume it does something.
+ */
+describe('<LocaleSwitcher />', () => {
+  it('renders one select with the expected locale options and no inline color classes', () => {
+    const { container } = renderWithIntl(<LocaleSwitcher />);
+
+    const selects = container.querySelectorAll('select');
+    expect(selects).toHaveLength(1);
+
+    const options = container.querySelectorAll('option');
+    expect(options).toHaveLength(LOCALES.length);
+
+    const values = Array.from(options).map((o) => o.getAttribute('value'));
+    expect(values).toEqual([...LOCALES]);
+
+    for (const option of options) {
+      expect(option.getAttribute('class')).toBeNull();
+    }
+  });
+});