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-12GitHub issuePublicFixed

Menu (Super+Space) needs several presses to open after focus moves to another monitor

Reported by ctarx · filed Sep 28, 2026 · open at source

In the audited area (menu) — decided by agents · verified. Not validated 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?
AreaIn the audited areamenu· Decided by agents · verified
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. So far: in the audited area (menu) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.

Original report

Menu (Super+Space) needs several presses to open after focus moves to another monitorrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happens

On a two-monitor setup, when I move focus to the other monitor and press Super+Space, the menu doesn't open on the first press. I have to press it several times before it shows up. When I stay on the same monitor, one press opens it every time.

This began after updating from r2304 to r6663 today, which pulled in #13419.

Expected

One Super+Space press opens the menu on the focused monitor, whichever monitor had the menu last.

Steps to reproduce

  1. Two monitors, both at scale 1.
  2. Open the menu with Super+Space on monitor A, then close it.
  3. Move focus to monitor B.
  4. Press Super+Space. The menu doesn't open. It only appears after one or more further presses.

Likely cause

#13419 introduced shell/Ui/OverlayWindow.qml. The overlay surface now persists between opens, parked as 1x1 on whichever screen it last used. It only switches screens when it is shown:

onShownChanged: if (shown) targetScreen = focusedScreen() || targetScreen
...
screen: targetScreen

On a PanelWindow, changing screen destroys the layer surface and creates a new one on the other output. Here that recreation happens during the same transition that sets shown to true, which raises the surface to the overlay layer and grants exclusive keyboard focus. On a different monitor, then, the first open lands on a surface being recreated. My guess is that the menu's opened state and the surface fall out of sync, so the next toggle() (shell.qml, isPluginOpen → hide) closes a menu that was never visible. Same-monitor opens don't change screen, which fits them working.

omarchy-menu toggle root takes the same shell.toggle path, so rebinding Super+Space to the command instead of the global shortcut doesn't help.

Possible direction: move the parked surface to the focused screen whenever the focused monitor changes, instead of doing it in the same step as showing it. Alternatively, wait for the recreated surface before setting shown.

Nothing relevant shows up in the Quickshell log.

System

  • Omarchy 4.0.0.r6663.g3faafba-1
  • quickshell 0.3.1-1, hyprland 0.56.2-3
  • CPU: AMD Ryzen 7 3700X
  • GPU: AMD Radeon RX 5700 XT (Navi 10)
  • Monitors: DP-1 2560x1440 (scale 1), DP-2 1920x1080 (scale 1)
View raw text
## What happens

On a two-monitor setup, when I move focus to the other monitor and press Super+Space, the menu doesn't open on the first press. I have to press it several times before it shows up. When I stay on the same monitor, one press opens it every time.

This began after updating from r2304 to r6663 today, which pulled in #13419.

## Expected

One Super+Space press opens the menu on the focused monitor, whichever monitor had the menu last.

## Steps to reproduce

1. Two monitors, both at scale 1.
2. Open the menu with Super+Space on monitor A, then close it.
3. Move focus to monitor B.
4. Press Super+Space. The menu doesn't open. It only appears after one or more further presses.

## Likely cause

#13419 introduced `shell/Ui/OverlayWindow.qml`. The overlay surface now persists between opens, parked as 1x1 on whichever screen it last used. It only switches screens when it is shown:

```qml
onShownChanged: if (shown) targetScreen = focusedScreen() || targetScreen
...
screen: targetScreen
```

On a PanelWindow, changing `screen` destroys the layer surface and creates a new one on the other output. Here that recreation happens during the same transition that sets `shown` to true, which raises the surface to the overlay layer and grants exclusive keyboard focus. On a different monitor, then, the first open lands on a surface being recreated. My guess is that the menu's `opened` state and the surface fall out of sync, so the next `toggle()` (`shell.qml`, `isPluginOpen` → `hide`) closes a menu that was never visible. Same-monitor opens don't change `screen`, which fits them working.

`omarchy-menu toggle root` takes the same `shell.toggle` path, so rebinding Super+Space to the command instead of the global shortcut doesn't help.

Possible direction: move the parked surface to the focused screen whenever the focused monitor changes, instead of doing it in the same step as showing it. Alternatively, wait for the recreated surface before setting `shown`.

Nothing relevant shows up in the Quickshell log.

## System

- Omarchy 4.0.0.r6663.g3faafba-1
- quickshell 0.3.1-1, hyprland 0.56.2-3
- CPU: AMD Ryzen 7 3700X
- GPU: AMD Radeon RX 5700 XT (Navi 10)
- Monitors: DP-1 2560x1440 (scale 1), DP-2 1920x1080 (scale 1)

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

  • Related PRpr/13792· confirmed
  • Fixed bypr/13809· confirmed
  • Fixed bypr/13903· 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.

  • Decided by agents · verified: in the audited area (menu)
  • Decided by agents · verified: matches no known issue

The outcome (valid, duplicate, not a bug, …) is not decided yet.