Proof Portal

Sign in
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-5077GitHub issuePublicReceived

Clock/calendar topbar popup gets stuck open, cannot regain focus without restarting the shell

Reported by Karrock · filed Sep 14, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #11105 (R-740). GitHub close reason: completed.

Open at source
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

Clock/calendar topbar popup gets stuck open, cannot regain focus without restarting the shellrevision 1 · captured 2026-10-04 12:10 UTC via poll

What happened

Clicking the clock widget in the topbar to open the calendar popup opened it as expected, but the popup then got stuck: it would not close on a repeat click of the clock icon, on clicking elsewhere, or on Escape. Keyboard/pointer focus stayed captured by the popup. The only way to recover was omarchy restart shell.

What was expected

Clicking the clock icon again (or clicking outside the popup / pressing Escape) should close the calendar popup and return focus to whatever was previously focused.

Steps to reproduce

  1. Click the clock/calendar widget in the topbar to open the calendar popup.
  2. Try to close it (click the icon again, click elsewhere, or press Escape).
  3. Observed: popup stays open and keyboard focus cannot be moved away from it.
  4. Only omarchy restart shell restores normal behavior.

Not yet confirmed reliably reproducible on demand — happened once so far. Single external/internal monitor (laptop only, no external display attached at the time).

System details

  • Omarchy version: 4.0.3-1 (stable channel)
  • Hyprland: 0.56.2 (v0.56.2, commit efb50993780079460b0cbed1363e2166a2de1d9f)
  • Monitor setup: single laptop panel (eDP-1, LG Display 0x05C0)

Notes for maintainers

shell/Ui/KeyboardPanel.qml (the shared popup component used by the clock/calendar panel among others) primes keyboard focus as WlrKeyboardFocus.Exclusive for ~75ms on open before settling to OnDemand, specifically to support keyboard-summoned popups. The file's own comments flag this transition as a known-fragile window (e.g. clicks from another output being misrouted with translated coordinates during the prime). While this report is from a single-monitor setup, the stuck-focus symptom (survives outside clicks, Escape, and re-clicking the anchor icon; requires a shell restart) suggests the panel got left in a state where open was true but the outside-click dismissal (dismissArea in KeyboardPanel.qml) and/or the PanelKeyCatcher's Escape handling never received/processed the event — possibly a focus-prime/OnDemand transition that didn't complete correctly.

View raw text
## What happened

Clicking the clock widget in the topbar to open the calendar popup opened it as expected, but the popup then got stuck: it would not close on a repeat click of the clock icon, on clicking elsewhere, or on Escape. Keyboard/pointer focus stayed captured by the popup. The only way to recover was `omarchy restart shell`.

## What was expected

Clicking the clock icon again (or clicking outside the popup / pressing Escape) should close the calendar popup and return focus to whatever was previously focused.

## Steps to reproduce

1. Click the clock/calendar widget in the topbar to open the calendar popup.
2. Try to close it (click the icon again, click elsewhere, or press Escape).
3. Observed: popup stays open and keyboard focus cannot be moved away from it.
4. Only `omarchy restart shell` restores normal behavior.

Not yet confirmed reliably reproducible on demand — happened once so far. Single external/internal monitor (laptop only, no external display attached at the time).

## System details

- Omarchy version: 4.0.3-1 (stable channel)
- Hyprland: 0.56.2 (v0.56.2, commit efb50993780079460b0cbed1363e2166a2de1d9f)
- Monitor setup: single laptop panel (eDP-1, LG Display 0x05C0)

## Notes for maintainers

`shell/Ui/KeyboardPanel.qml` (the shared popup component used by the clock/calendar panel among others) primes keyboard focus as `WlrKeyboardFocus.Exclusive` for ~75ms on open before settling to `OnDemand`, specifically to support keyboard-summoned popups. The file's own comments flag this transition as a known-fragile window (e.g. clicks from another output being misrouted with translated coordinates during the prime). While this report is from a single-monitor setup, the stuck-focus symptom (survives outside clicks, Escape, and re-clicking the anchor icon; requires a shell restart) suggests the panel got left in a state where `open` was true but the outside-click dismissal (`dismissArea` in `KeyboardPanel.qml`) and/or the `PanelKeyCatcher`'s Escape handling never received/processed the event — possibly a focus-prime/OnDemand transition that didn't complete correctly.

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.