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.
4.0.3 menu: stale highlight ghosts accumulate on rows while keyboard-scrolling long lists
Reported by somnten · filed Sep 13, 2026Closed upstream on 2026-09-13 by its own reporter somnten. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.
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
Environment
- Omarchy 4.0.3-1, quickshell 0.3.1-1, stable channel
- Hyprland, 3440x1440@50 scale 1, VRR off, tearing off
- Reproduces on both Intel iGPU and after full shell restart + cleared qmlcache
Summary
Keyboard-navigating a long menu list (e.g. Setup > Plugins > Disable plugin, ~30+ rows so the list scrolls) accumulates stale highlight "ghosts": previously-selected rows keep a faint selectedBackground tint while the real cursor highlight moves on. Ghosts persist (do not fade) and stack up the longer you arrow, until the card looks corrupted.
Repro
- Open omarchy menu > Setup > Plugins > Disable plugin (any menu long enough to scroll)
- Hold/press Down steadily past the fold so positionViewAtIndex starts scrolling
- Observe rows that previously held the cursor keep a dim highlight; the current row is bright
- Ghosts remain after navigation stops; they only clear when the list content re-lays-out (filter, reopen, provider refresh) or when the pointer physically moves over the card (frame gets repainted there)
Notes
- Same list renders clean when it fits without scrolling (short menus never ghost)
- Mouse-driven navigation does not ghost (PointerMoveGate path forces repaints per move)
- Suspect the ListView delegate highlight is only invalidated within the region Qt thinks is damaged: manual contentY scrolling in revealCursor() (Menu.qml) plus BorderSurface delegate color swap leaves stale damage outside it. Possibly only when a scrollbar is also shown (opacity change on scroll may limit the damaged region)
- No QML errors in qslog during repro
Workaround
Move the physical mouse (even 1px) over the menu: ghosts repaint away instantly.
Happens on both stable and the quattro branch code I inspected (revealCursor()/delegate structure identical there; select() gained nextSelectable but the scroll/paint mechanics are unchanged).
View raw text
### Environment - Omarchy 4.0.3-1, quickshell 0.3.1-1, stable channel - Hyprland, 3440x1440@50 scale 1, VRR off, tearing off - Reproduces on both Intel iGPU and after full shell restart + cleared qmlcache ### Summary Keyboard-navigating a long menu list (e.g. Setup > Plugins > Disable plugin, ~30+ rows so the list scrolls) accumulates stale highlight "ghosts": previously-selected rows keep a faint selectedBackground tint while the real cursor highlight moves on. Ghosts persist (do not fade) and stack up the longer you arrow, until the card looks corrupted. ### Repro 1. Open omarchy menu > Setup > Plugins > Disable plugin (any menu long enough to scroll) 2. Hold/press Down steadily past the fold so positionViewAtIndex starts scrolling 3. Observe rows that previously held the cursor keep a dim highlight; the current row is bright 4. Ghosts remain after navigation stops; they only clear when the list content re-lays-out (filter, reopen, provider refresh) or when the pointer physically moves over the card (frame gets repainted there) ### Notes - Same list renders clean when it fits without scrolling (short menus never ghost) - Mouse-driven navigation does not ghost (PointerMoveGate path forces repaints per move) - Suspect the ListView delegate highlight is only invalidated within the region Qt thinks is damaged: manual contentY scrolling in revealCursor() (Menu.qml) plus BorderSurface delegate color swap leaves stale damage outside it. Possibly only when a scrollbar is also shown (opacity change on scroll may limit the damaged region) - No QML errors in qslog during repro ### Workaround Move the physical mouse (even 1px) over the menu: ghosts repaint away instantly. Happens on both stable and the quattro branch code I inspected (revealCursor()/delegate structure identical there; select() gained nextSelectable but the scroll/paint mechanics are unchanged).
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.