Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

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

Inbox
ReportR-4863GitHub issuePublicFixed

Brave Origin window class not matched by browser.lua opacity regex, stays translucent even when focused

Reported by pkovzz · filed Sep 3, 2026Closed upstream on 2026-09-03 by its own reporter pkovzz. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.

Received and recorded verbatim. Nothing has been checked yet.

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

Brave Origin window class not matched by browser.lua opacity regex, stays translucent even when focusedrevision 1 · captured 2026-10-04 12:10 UTC via poll

Description

Brave Origin windows never receive full opacity when focused — they stay slightly translucent (background visible through the window) even while active. Firefox and Chrome/Chromium do not show this.

Root cause

default/hypr/apps/browser.lua tags Chromium-family browsers so they get bumped off the generic default-opacity tag and up to full opacity when focused:

o.window("((google-)?[cC]hrom(e|ium)|[bB]rave-browser|[mM]icrosoft-edge|Vivaldi-stable|helium)", { tag = "+chromium-based-browser" })
o.window({ tag = "chromium-based-browser" }, { tag = "-default-opacity", tile = true, opacity = "1.0 0.985" })

Brave Origin's actual window class is brave-origin (confirmed via hyprctl clients), not Brave-browser. The regex alternative [bB]rave-browser doesn't match it, so Brave Origin windows never get the chromium-based-browser tag and are left on the generic:

o.window({ tag = "default-opacity" }, { opacity = "0.985 0.96" })

...which caps opacity at 0.985 even while focused/active, and drops to 0.96 when unfocused. Hence the visible translucency in Brave Origin specifically, and not in Firefox/Chrome (whose classes do match their respective patterns).

Note: this is a different, narrower case than #9784 (web app classes like brave-<host>__-Default failing under RE2::FullMatch). This is the plain Brave Origin browser window class itself never being listed as a chromium-based-browser alternative in the first place.

Steps to reproduce

  1. Launch Brave Origin.
  2. Run hyprctl clients and note class: brave-origin.
  3. Observe the window is translucent (desktop visible through it) even while focused/active.
  4. Compare with Firefox or Chrome, which reach full opacity when focused.

Expected behavior

Brave Origin windows should reach full opacity (1.0) when focused, matching other Chromium-based/Firefox-based browsers.

Proposed solution

Add brave-origin as an alternative in the chromium-based-browser regex in default/hypr/apps/browser.lua:

o.window("((google-)?[cC]hrom(e|ium)|[bB]rave-browser|brave-origin|[mM]icrosoft-edge|Vivaldi-stable|helium)", { tag = "+chromium-based-browser" })

(Alternatively/additionally, if Brave Origin Beta uses a distinct class such as brave-origin-beta, that should be covered too — worth confirming.)

System

  • Omarchy version: 4.0.2-1
  • Hyprland: 0.56.2 (v0.56.2, commit efb5099)
  • Kernel: 7.1.9-arch1-2
  • CPU: 12th Gen Intel Core i5-12400F
  • GPU: AMD Radeon RX 6700/6700 XT/6750 XT (Navi 22)
  • Browser: Brave Origin
  • Window class confirmed via hyprctl clients: brave-origin

Note: omarchy debug --no-sudo --print (referenced in the contributing guide) isn't a recognized command on this install (omarchy commands --all has no debug entry), so no diagnostic log/URL is attached. Happy to attach one if pointed to the current equivalent.

View raw text
### Description

Brave Origin windows never receive full opacity when focused — they stay slightly translucent (background visible through the window) even while active. Firefox and Chrome/Chromium do not show this.

### Root cause

`default/hypr/apps/browser.lua` tags Chromium-family browsers so they get bumped off the generic `default-opacity` tag and up to full opacity when focused:

```lua
o.window("((google-)?[cC]hrom(e|ium)|[bB]rave-browser|[mM]icrosoft-edge|Vivaldi-stable|helium)", { tag = "+chromium-based-browser" })
o.window({ tag = "chromium-based-browser" }, { tag = "-default-opacity", tile = true, opacity = "1.0 0.985" })
```

Brave Origin's actual window class is `brave-origin` (confirmed via `hyprctl clients`), not `Brave-browser`. The regex alternative `[bB]rave-browser` doesn't match it, so Brave Origin windows never get the `chromium-based-browser` tag and are left on the generic:

```lua
o.window({ tag = "default-opacity" }, { opacity = "0.985 0.96" })
```

...which caps opacity at 0.985 even while focused/active, and drops to 0.96 when unfocused. Hence the visible translucency in Brave Origin specifically, and not in Firefox/Chrome (whose classes do match their respective patterns).

Note: this is a different, narrower case than #9784 (web app classes like `brave-<host>__-Default` failing under `RE2::FullMatch`). This is the plain Brave Origin browser window class itself never being listed as a chromium-based-browser alternative in the first place.

### Steps to reproduce

1. Launch Brave Origin.
2. Run `hyprctl clients` and note `class: brave-origin`.
3. Observe the window is translucent (desktop visible through it) even while focused/active.
4. Compare with Firefox or Chrome, which reach full opacity when focused.

### Expected behavior

Brave Origin windows should reach full opacity (1.0) when focused, matching other Chromium-based/Firefox-based browsers.

### Proposed solution

Add `brave-origin` as an alternative in the chromium-based-browser regex in `default/hypr/apps/browser.lua`:

```lua
o.window("((google-)?[cC]hrom(e|ium)|[bB]rave-browser|brave-origin|[mM]icrosoft-edge|Vivaldi-stable|helium)", { tag = "+chromium-based-browser" })
```

(Alternatively/additionally, if Brave Origin Beta uses a distinct class such as `brave-origin-beta`, that should be covered too — worth confirming.)

### System

- Omarchy version: 4.0.2-1
- Hyprland: 0.56.2 (v0.56.2, commit efb5099)
- Kernel: 7.1.9-arch1-2
- CPU: 12th Gen Intel Core i5-12400F
- GPU: AMD Radeon RX 6700/6700 XT/6750 XT (Navi 22)
- Browser: Brave Origin
- Window class confirmed via `hyprctl clients`: `brave-origin`

Note: `omarchy debug --no-sudo --print` (referenced in the contributing guide) isn't a recognized command on this install (`omarchy commands --all` has no `debug` entry), so no diagnostic log/URL is attached. Happy to attach one if pointed to the current equivalent.

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

  • Fixed bypr/10446· confirmed

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.