Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Dark themes with a tinted near-black background render Chromium chrome as loud saturated blue (BrowserThemeColor is a seed, not a paint color)
Reported by 1azza · filed Sep 7, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7624 (R-1620). GitHub close reason: completed.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
What happened
Dark themes whose colors.toml background is a near-black with a slight hue tint render the Chromium tab strip/toolbar as a loud, fully saturated tone of that hue instead of the theme's background color.
With a theme using background = "#000107" (near-black, tiny blue tint), Chromium's tab strip/toolbar renders as saturated blue #0018AC (measured from screenshots). Omarchy's own fallback #1c2027 (see install/helpers/browser-policy.sh) has the same blue hue and produces the same result, so this also affects the out-of-the-box experience for many dark themes.
Why
BrowserThemeColor is not a paint color — Chromium derives the browser chrome color from it as a seed, adjusting lightness while preserving HSL saturation. At the luminance extremes HSL saturation is degenerate:
- a near-black seed has a tiny
max+min, sos = (max-min)/(max+min)→ 1.0 for any tint (e.g.#000107:s = 7/7 = 1.0) - a near-white seed whose max channel is 255 also yields
s = 1.0
So a barely-tinted near-black renders as a fully saturated dark tone of that hue. This is the same mechanism reported for light themes in #7624 (near-white #fffcf0 → saturated yellow #ffde5a) — that issue's analysis says dark themes are unaffected, but a dark seed with a small tint is affected the same way.
Verified experiments (Chromium 151.0.7922.173, Arch)
Writing these directly into /etc/chromium/policies/managed/color.json and restarting Chromium:
| Seed (BrowserThemeColor) | Rendered tab strip | Note |
|---|---|---|
#000107 | #0018AC (saturated blue) | same ~231° hue as the seed, chroma boosted |
#ff0000 | red | already maximal chroma, hue survives |
#222222 (neutral) | #131111 (neutral dark) | neutral seeds are fine |
#738555 (olive) | dark olive tones | hue survives |
The profile had no user theme, no extension theme and no NTP custom background, so the rendering comes purely from the seed derivation.
Steps to reproduce
- Create a custom theme with
colors.tomlcontainingbackground = "#000107"(or any near-black with a small hue tint) omarchy theme set <theme>- Open Chromium → the tab strip/toolbar is saturated blue, not near-black
System
- Omarchy 4.0.2-1
- Chromium 151.0.7922.173 Arch Linux
- AMD Ryzen 5 PRO 8540U (Radeon 740M iGPU), Hyprland/Wayland
Notes
- #10054 / #10056 (
BrowserColorScheme: "device"being an invalid policy value) is a separate problem — fixing it does not change the rendered color. - Fix direction: neutralize degenerate-saturation seeds when generating
chromium.theme(clampmax+min <= 16ormax == 255seeds with small chroma to their channel average), and make the fallback#1c2027neutral. A branch with this change plus tests is ready — happy to open a PR.
View raw text
### What happened Dark themes whose `colors.toml` background is a near-black with a slight hue tint render the Chromium tab strip/toolbar as a loud, fully saturated tone of that hue instead of the theme's background color. With a theme using `background = "#000107"` (near-black, tiny blue tint), Chromium's tab strip/toolbar renders as saturated blue `#0018AC` (measured from screenshots). Omarchy's own fallback `#1c2027` (see `install/helpers/browser-policy.sh`) has the same blue hue and produces the same result, so this also affects the out-of-the-box experience for many dark themes. ### Why `BrowserThemeColor` is not a paint color — Chromium derives the browser chrome color from it as a *seed*, adjusting lightness while preserving HSL saturation. At the luminance extremes HSL saturation is degenerate: - a near-black seed has a tiny `max+min`, so `s = (max-min)/(max+min)` → 1.0 for any tint (e.g. `#000107`: `s = 7/7 = 1.0`) - a near-white seed whose max channel is 255 also yields `s = 1.0` So a barely-tinted near-black renders as a fully saturated dark tone of that hue. This is the same mechanism reported for light themes in #7624 (near-white `#fffcf0` → saturated yellow `#ffde5a`) — that issue's analysis says dark themes are unaffected, but a dark seed with a small tint is affected the same way. ### Verified experiments (Chromium 151.0.7922.173, Arch) Writing these directly into `/etc/chromium/policies/managed/color.json` and restarting Chromium: | Seed (BrowserThemeColor) | Rendered tab strip | Note | | --- | --- | --- | | `#000107` | `#0018AC` (saturated blue) | same ~231° hue as the seed, chroma boosted | | `#ff0000` | red | already maximal chroma, hue survives | | `#222222` (neutral) | `#131111` (neutral dark) | neutral seeds are fine | | `#738555` (olive) | dark olive tones | hue survives | The profile had no user theme, no extension theme and no NTP custom background, so the rendering comes purely from the seed derivation. ### Steps to reproduce 1. Create a custom theme with `colors.toml` containing `background = "#000107"` (or any near-black with a small hue tint) 2. `omarchy theme set <theme>` 3. Open Chromium → the tab strip/toolbar is saturated blue, not near-black ### System - Omarchy 4.0.2-1 - Chromium 151.0.7922.173 Arch Linux - AMD Ryzen 5 PRO 8540U (Radeon 740M iGPU), Hyprland/Wayland ### Notes - #10054 / #10056 (`BrowserColorScheme: "device"` being an invalid policy value) is a separate problem — fixing it does not change the rendered color. - Fix direction: neutralize degenerate-saturation seeds when generating `chromium.theme` (clamp `max+min <= 16` or `max == 255` seeds with small chroma to their channel average), and make the fallback `#1c2027` neutral. A branch with this change plus tests is ready — happy to open a PR.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.